Microservices are an increasingly popular approach to building cloud-native applications. We hear about them from social media, conferences, webinars, books, framework vendors, and colleagues. It seems like they are the only way to move forward.
But are they? To answer this question, we first need to explore why microservices are so useful, what their downsides are, and what the alternatives are.
Microservice architecture, or microservices, is a distinct method of developing software systems that have grown in popularity in recent years.
In short, a microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, such as HTTP API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is minimal centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Web application features are usually contained in a single codebase. In a microservice architecture, the codebase is split into individual components called microservices. Every microservice encapsulates a specific business function, such as user management, user roles, an e-commerce cart, search engine, or social media logins. When you separate each business need into a microservice, issues that arise in one area of the application will not affect the system as a whole.
Each microservice communicates with other services through HTTP connections. Using HTTP allows developers to deploy microservices using their existing toolset. In addition, they can easily connect to and wrap 3rd-party APIs.
But there is a communication challenge when using a microservice architecture. Microservices have to find and communicate with other microservices that comprise your application when, at scale, there may be many instances of each microservice. To solve this, microservices need to announce that they exist and then find the required microservices. This challenge is called “service discovery.”
A microservice architecture works best when each microservice is stateless. This means that each request to a microservice is completely independent of the requests that came before it. It allows for the greatest flexibility when it comes time to scale. Furthermore, each microservice maintains its own data. This eliminates the database as a “single point of failure.”
The above diagram illustrates a general architecture of a microservice application. Each service has its own database and does not connect directly to the database of other services.
Web and mobile applications communicate with these services through an API gateway. An API gateway can be a proxy but can also act as a data transformer, serving the relevant data to the right page. By loading product info into a mobile application, the number of fields may be reduced, which saves bandwidth. Ideally, an integration engineer should take ownership of the API gateway.
The API gateway is as important as any other microservice. In fact, much more important is the only bottleneck of your application, and a failure in the API gateway can bring down the entire application. Hence, it should be as robust as possible.
The event queue acts as a transport layer for communication between microservices.
There is a good chance you have heard the terms monoliths, microservices, and SOA. But what do they really mean?
Monolithic architecture runs on a single application layer that joins all architecture functionalities. This architecture form doesn’t involve as many actors as other architectural styles. To build a web architecture using a monolithic approach, you would start developing its front-end and enable its access to data.
Let’s imagine that you are building a new taxi application to compete with Uber and Ola. You would create a new project manually or by using a generator that comes with Rails, Spring Boot, Play, or Maven. This new application would have a modular architecture, shown in the following diagram:
Unlike monoliths, microservice architectures consist of independent services with a nothing-shared architecture.
SOAs, Service-Oriented Architectures, usually incorporate functions into small and mid-sized applications. They try to keep the complexity of each app or functionality very low and make them communicate over a set APIs. The services do many things that are limited to the scope of a single functionality.
SOAs usually provide good flexibility but come at a cost. Even though each piece evolves independently and does not impact the others and it is simple, the architecture itself becomes more complex.
Isn’t microservice another name for SOA? SOA is a broader framework and can mean a wide variety of things. Some reject the SOA tag altogether, while others consider microservices to be a refined form of SOA. In any case, the differences are clear enough to justify a distinct “microservice” concept.
The SOA model has more dependent ESBs, with microservices using faster messaging mechanisms. SOA focuses on imperative programming, whereas microservice architecture focuses on responsive-actor programming. Moreover, SOA models tend to have an outsized relational database, while microservices use NoSQL or micro-SQL databases. But the real difference has to do with the architecture methods used to arrive at an integrated set of services in the first place.
Let’s look at an online shopping site. This site would have a handful of different features: a product catalogue, user accounts, and shopping carts to name a few.
A development organization using SOA would split the shopping site into major sets of business logic, then each set will be developed as a separate application to be integrated.
An organization using microservices would break up the shopping cart into smaller task-oriented services. Instead of a shopping cart application, there might be tax calculation, add and remove an item, shipping, billing, and order services.
To save you some clicks, we will explain the difference between monoliths, microservices, and SOA using one picture that represents them as food.
Each module, being in different server nodes, can scale horizontally at a rate independent of other modules. This will be difficult to achieve with a single, large monolithic service.
Microservice architecture can be used with different programming languages, communication, monitoring, or data persistence tools. This is great for choosing a tool for the job at hand and innovates by being early adopters of new technologies.
Keeping modularity and encapsulation IS possible in both monoliths and microservices. Even so, it can be quite difficult, and we have been trying to do it for decades and despite SOLID rules. The physical partition of the application enforces a logical partition in separate servers/nodes. This physical isolation makes it unnatural to cross the bounded context boundaries.
We can leave older versions of the microservice running if needed, so a microservice can evolve and break backward compatibility. But, it does not get cluttered with code to support older versions.
Microservice architecture is not a technical choice. It should align with and facilitate the goals of your organization. Your customer-facing website is quite different from your payment provider interface. It has a different audience, metrics, testing strategies, and timelines. A microservice architecture allows these functions to evolve in parallel with a minimal amount of developer coordination and planning. Here’s a diagrammatic representation for quick understanding:
Microservices are organized around business capabilities, not a specific project or product requirement. This enables technology teams to reuse services and reduce costs.
Large-scale and complex enterprise applications are three-tier. Microservices let each service manage its own database, different database instances or systems. This approach is called Polyglot Persistence. Here is a diagrammatic representation for better understanding:
While technology teams have to deploy an entire application again because of a small change in the code, with microservices this deployment becomes easy. The scope of deployment is smaller and only the service that has a problem needs to be redeployed.
Failure in one service does not impact other services. If you have monolithic service errors in a module, it can impact other modules and functionalities as well.
Less dependencies make microservices easy to change and test.
Microservices improve fault isolation. Complex applications are broken into separate service components and deployed on multiple servers. The failure of one service or module will not impact the entire application. A single service fault can be replaced with another service, increasing the application’s availability.
Understanding how an application is developed is important when there is a change in development teams. In a distributed development project, microservice architecture helps development teams understand the entire functionality.
An individual microservice may be well-tested, but in conjunction with some common microservices and programs, it is hard to test every configuration. As you combine them, they may interact in unforeseen ways.
It is not always easy to tell where microservices reside, which can make securing them a headache. This also provides more opportunities to penetrate the system. Savvy DevOps teams are moving to a more granular security policy called micro-segmentation to get around this problem, but the solution isn’t universal yet.
It will take time and discipline to replace monolith with a microservices architecture, but many companies have accomplished this and found the investment worthwhile.
While the system as a whole may live for a long time, its components—the containers—do not. They live and die quickly.
This situation presents new challenges to many areas of software engineering. One of them is monitoring. How can an operator make sure that a system remains healthy if existing monitoring tools are unable to function in this new reality?
To solve this challenge, VironIT developed Environment Overseer, a service for real-time monitoring environments. This is built on the principle of microservice architecture. Service finds the root cause of the microservice architecture problem and allows it to be solved as soon as possible.
“Microservice” has become a popular name for this architectural style, but this name does lead to an unfortunate focus on the size of the service and arguments about what constitutes “micro.” A common question people ask is, “How big or small should my microservice be?” One common answer is that the size of a microservice is variable, but it should be coded by no more than a dozen people.
The largest sizes are reported following Amazon’s notion of the Two Pizza Team. This means that the entire team can be fed by two pizzas.
On the smaller size scale, a team of six would support about six services. In general, the team size, including Dev, QA, and Product for a Microservice should be seven members at most.
Large-scale companies like Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Twitter, PayPal, Bluemix, and The Guardian have migrated from monolithic to microservices architecture. Let’s look at some of the success stories to see the results.
Netflix has a widespread microservice architecture. It receives more than one billion calls every day from 800 different devices to its streaming-video API. Each API call then prompts around five additional calls to the backend service.
Another example is Amazon, for instance. All we can see is the website. Amazon made a change from the Obidos monolithic to a microservice with encapsulated databases and “two-pizza” teams. Its microservices receive countless calls from a variety of applications. Amazon has never used the term “microservices.” Those in the microservices movement draw a lot of inspiration from Amazon’s experience.
The auction site eBay is yet another example that has gone through the same transition. Its core application comprises several autonomous applications. Each one executes the business logic for different functional areas.
Walmart was failing on Black Friday for two years in a row. It could not handle 6-million page views per minute and retain any kind of positive user experience, so it re-platformed to a microservices architecture.
Migrating to microservices actually brought notable results:
Spotify serves more than 75 million active users per month, with an average session length of 23 minutes.
To avoid synchronization hell within the organization, Spotify built a microservice architecture. These teams are autonomous, and their mission does not overlap with other teams’ missions.
Now, Spotify has around 90 teams, 600 developers, and 5 development offices on 2 continents.
There are two ways to structure the frontend and backend in a microservices architecture:
Decomposing a monolith into a microservice, we need to think of several dimensions that can support the decision:
Most projects don’t need microservices architecture.
A monolithic architecture makes sense for simple, lightweight applications. If your application is working well and doesn’t need changes, then adopting microservices will offer very little benefit. After all, microservices bring quirks and difficulties to the development process. Keeping all the new services running can sometimes feel like juggling balls. Adopting tools such as Kubernetes or Docker can take some change as well.
The microservices architecture is a better choice for complex, evolving applications despite the drawbacks and implementation challenges. Microservices are a response to hitting the ceiling. This happens to every successful software development project. Traditional monolithic application architectures do not scale anymore. The database grows too large, or there are too many millions of lines of code, or you can no longer add features.
Microservices are not a silver bullet for challenges of monolithic architecture, but they can empower your team to reach new levels of scale and agility.
Whether you need to improve application or start out with a new one, VironIT, software development company, has the team and experience to develop your vision.
Our team has expertise in:
Contact us today for an intuitive and fast app solution for your business or enterprise.