Microservices have, for many companies like Amazon, Nextflix and Spotify, become the architecture of choice for application development.
A component of cloud native computing, microservices are mini applications that make up a larger application. Each microservice is responsible for doing one discrete piece of functionality and doing it well.
Take an eCommerce site owned by ACME as an example. In a microservices architecture, that may look like one application, but it really is a combination of dozens or even hundreds of microservices like product catalogs, user profiles, and order processing. Application Programming Interfaces, referred to as APIs, are gateways between these and other disparate applications. Microservices are decentralized and can run on different servers but still work together routing between services using API communication. APIs allow these micro-applications to communicate and transfer information to one another as well as other outside applications. For instance, ACME’s eCommerce site order processing app might allow customers to pay with PayPal. When they go to check out and pay with PayPal, it may appear to them as if they’re still on eCommerce website, but they’re actually communicating with PayPal.
The traditional way of creating applications is with a monolithic architecture, which is becoming outdated. The term “monolith” refers to a single block of stone of considerable size. Although there still may be different sections for certain categories, monolithic apps are built with all the lines of code contained in one block. If one part of the monolithic app goes down, it can have ripple effects and can potentially shut down your entire application.
A power outage knocked a Netflix data center offline for three days back in its DVD shipping days, which was a big reason why the company transitioned to microservices. If one microservice goes down, the other microservices remain online. So, if the recommendation microservice were to go down, users might not see suggestions that Netflix recommends they watch based on their previous viewing practices, but users would still be able to watch shows.
A microservices application can scale with fewer resources than a monolithic application. If you need to scale the catalog section of an application, with microservices, you just scale that one single application. In a monolithic application, you have to scale the entire application. For example, let’s say the catalog microservice is housed in a container, and you need to spin up three more of those containers to suit the traffic. You wouldn’t need to spin up any more instances of any of the other microservices as long as the traffic flow to them is fine. But with a monolithic application, the catalog portion is not separate from the rest of the application. The application is all one big unit, which means you have to spin up three more applications. It takes a lot more resources—specifically CPU and memory—to run a monolithic application than a microservices application. When you spin up those three giant applications, you will be paying for those resources whether your application is housed on-premises or in the cloud.
Compared to a monolithic application, a microservice is broken down to its smallest component. Enterprises often have separate IT teams that are tasked with creating and servicing a specified handful of microservices. This allows companies to assign focused teams that can take ownership of their microservices, making it easier to update and improve a certain function without worrying about affecting the rest of the application.
Different languages can be used to develop different microservices. For example, one microservice could be developed in Java, and another could be developed using NodeJS. A third might be developed in C#. This allows individual developers to choose the language best-suited for a given problem.
If you make a change to the product catalog, you’ll only need to test that specific microservice. You don’t need to test and deploy the rest of the application.
In a monolith, when one piece of code changes, you’ll need to test the entire application before redeploying. Making a change in the product catalog in a monolithic app could cause a bug in the order processing function. Fixing that bug in the order processing function could then cause an error in the user profile. It can feel like playing whack-a-mole.
There are more moving pieces like programming languages, processes, APIs, databases and servers when using microservices architecture. Carefully planning out this architecture is critical. In Fig. 1 you can see the architecture of an application containing three microservices.
Fig. 2 Source
There could be dozens or hundreds of microservices in an application, making monitoring and managing them far more complex than for a monolithic application. Troubleshooting errors with microservices can be far more difficult than doing the same thing for a monolithic application where all your code is in one block. With a monolithic application, you can use a debugging tool to run the code and tell it to stop when it gets to the part where the trouble lies. You can then look at the error and investigate it. With microservices, you’ll need to use distributed tracing tools to see how user requests are performing in different services. A single user request can travel through hundreds of microservices. To quickly identify where problems lie, tracing tools provide you with a central overview of how requests are performing across services. The tools help you capture user requests as they travel through every service and measure things like latency, so you can discover the location of the problem, the cause of the problem, and the owners of the particular microservice, so you can notify them so they can fix it.
Culture can be a challenge if you are moving from a monolithic to a microservices architecture.
Each development team operates independently, which means they manage the entire lifecycle of the microservice. The people on the team need the skills and experience to develop, test and deploy all the microservices that make up their part of the overall application. If they aren’t used to working in a DevOps environment, this will be a change. While there are benefits to this shift, it can be tough for some companies to manage learning DevOps.
Want to learn more? ExitCertified can help you select and execute IT training courses for all your needs to help teams rapidly acquire new skills and optimize business results.
Take the courses you need to build cloud native applications and microservices to help transform your business.
Take the courses you need to build cloud native applications to help transform your business
Start Learning
With the skills gap expanding across multiple industries, it can be challenging for employees to acquire the knowledge and expertise they need to thrive. Moving forward, we will explore how L&D teams may bridge the skills gap in 2023.
Keeping data safe is of the utmost importance in our modern digital world. Continue reading to learn more about keeping government data safe in the cloud.
As the shifting global economy makes it more difficult to stay competitive, it’s important for organizations to utilize strategic project-management processes.
