Microservices, Explained

Let’s imagine we are planning to build a new booking management application for our space flight business. The technology required to operate flights to space would surely be pretty cutting-edge, and we would want the application to be written in the newest app development technologies. After gathering requirements, and understanding which features we want, the first step would be to create a project using Maven, NPM, or any other builder.
Until recently, this one project would have been the single stop for all the code, APIs, and configurations. In order to build and deploy the application, it was necessary to compile this project, as big as it might have been, make sure that all of its dependencies were available, and only then could it be packaged or deployed. The build process was complicated, fragile, and sometimes very slow. Martin Fowler explains in his microservices blog how these projects work—a monolithic application which is built as a single unit can be successful, but increasingly people are feeling frustrations with them—especially as more applications are being deployed to the cloud.
“We have been working with the core ideas behind services for five decades now,” said Greg Young, while explaining the core ideas that led to the current microservices approach at the recent Microservices Conference in London. And yet, not until recently did R&D groups start to understand that splitting the application into smaller units—where each unit is completely independent—can have a huge impact on the development, testing, and delivery of their software. Developing these small units—microservices—instead of one monolithic application adds new dimensions of diversity and flexibility into the process.
 

Getting Started

So, we understand that our application is going to be divided into many small parts, and we are going to have the ability to develop and maintain each and every one of them on its own—but what next? After understanding how the application is going to be developed, we need to understand how it is going to be deployed. Having a set of separate services allows us to deploy them in different ways: either all on one machine, or with a service instance per VM or Docker container.
When planning the deployment of our app, we take into account the cost of maintaining the hosts, and the structure of our backend. We then select a cloud provider—Amazon, Azure, Google Cloud or others—and determine how many instances are required and how we will scale in case of high usage. Monitoring the production environment and identifying components under load—for example, extensive flight bookings—within the microservices architecture allows us to specifically scale this service and deal with such problems easily.
The build process also requires some attention. We no longer require one big pipeline to go through the huge code base, compile every part of it, upload artifacts to a shared repository, and pull them for deployment.
Each microservice has a small CI/CD process of its own, allowing parallel compilation and deployment. So for our booking application, we would create a separate compilation unit for the flight search, the booking, and flight status services, and another for the app UI that integrates with all of these services. Each service will have its own domain where the tests and deployment will be executed.
 

Tackling Complexity

Each of our three microservices is basically a mini-application that has its own architecture consisting of business logic. Some microservices would expose an API that’s consumed by other microservices or by the application’s clients. Other microservices might implement the web UI. As already mentioned, each instance will be an independent cloud VM or a Docker container at runtime.
This new architecture should change the way we approach several aspects of the R&D methods, such as the integration between services in different layers and testing the app.
Each team, building a different service for the application, is now fully independent and is required to expose and support APIs to the other services. This requires close communication and a high level of trust between teams, which is something that takes time to build.
When building an automation test suite for the app, whether for testing the API level or the UI level, the suites should be divided into end-to-end tests that cover the full functionality of the application and verify the functionality of each service on its own. This makes it possible to update one service at a time, and still make sure the application is not affected.
 

Best Practices

A few things to consider when beginning with microservices:
 

Plan your development

Each service must be as small as possible, and yet independent. This requires a very specific architecture and can only be achieved if the whole R&D group adheres to the same standards. At the same time, teams should have the freedom to operate in the way they want, with the management’s full support.
 

Pay attention to containers

If only one service is going to be deployed per host, this host should be deployed fast, and be flexible and easily scalable. All these can be achieved with containers. Use the right tool to manage the containers and control how environments behave and react to changes.
 

Take a DevOps approach

Both Ops and R&D teams should share responsibility for production environment and be involved in the deployment process. Collaboration between the two teams is critical for the success of any microservices deployment.
Overall, a well designed, healthy and successful microservices architecture is not easy to achieve, but definitely worth the effort as it improves almost every aspect of the application—from its development to delivery and usage by customers.
As microservices facilitate faster, more agile deployments, it’s especially important for an organization to ensure they maintain visibility and control over their architecture. Explore the CloudCheckr platform to find out how we help keep your infrastructure in check.