Looking back 4-5 years ago, the sentiment around microservices architecture has changed quite a bit. First, it was in the hype phase when after seeing the success stories of companies like Netflix, Amazon, and Gilt.com developers thought that microservices are the de facto of application development. Cut to now, we have realized that microservices is yet another architectural style which when applied to the right problem in the right way works amazingly well but comes with its own pros and cons.
To get an understanding of what exactly microservices are, when we should use them, when not to use them, we sat with Jaime Buelta, the author of Hands-On Docker for Microservices with Python. Along with explaining microservices and their benefits, Buelta shared some best practices developers should keep in mind if they decide to migrate their monoliths to microservices.
[box type=”shadow” align=”” class=”” width=””]
Further Learning
Before jumping to microservices, Buelta recommends building solid foundations in general software architecture and web services. “They’ll be very useful when dealing with microservices and afterward,” he says.
Buelta’s book, Hands-on Docker for Microservices with Python aims to guide you in your journey of building microservices. In this book, you’ll learn how to structure big systems, encapsulate them using Docker, and deploy them using Kubernetes.
[/box]
Microservices: The benefits and risks
A traditional monolith application encloses all its capabilities in a single unit. On the contrary, in the microservices architecture, the application is divided into smaller standalone services that are independently deployable, upgradeable, and replaceable. Each microservice is built for a single business purpose, which communicates with other microservices with lightweight mechanisms.
Buelta explains, “Microservice architecture is a way of structuring a system, where several independent services communicate with each other in a well-defined way (typically through web RESTful services). The key element is that each microservice can be updated and deployed independently.”
Microservices architecture does not only dictates how you build your application but also how your team is organized.
[box type=”shadow” align=”” class=”” width=””]”Though [it] is normally described in terms of the involved technologies, it’s also an organizational structure. Each independent team can take full ownership of a microservice. This allows organizations to grow without developers clashing with each other,” he adds. [/box]
One of the key benefits of microservices is it enables innovation without much impact on the system as a whole. With microservices, you can do horizontal scaling, have strong module boundaries, use diverse technologies, and develop parallelly. Coming to the risks associated with microservices, Buelta said, “The main risk in its adoption, especially when coming from a monolith, is to make a design where the services are not truly independent. This generates an overhead and complexity increase in inter-service communication.”
He adds, “Microservices require a high-level vision to shape the direction of the system in the long term. My recommendation to organizations moving towards this kind of structure is to put someone in charge of the “big picture”. You don’t want to lose sight of the forest for the trees.”
Migrating from monoliths to microservices
Martin Fowler, a renowned author and software consultant, advises going for a “monolith-first” approach. This is because using microservices architecture from the get-go can be risky as it is mostly found suitable for large systems and large teams.
Buelta shared his perspective, “The main metric to start thinking into getting into this kind of migration is raw team size. For small teams, it is not worth it, as developers understand everything that is going on and can ask the person sitting right across the room for any question. A monolith works great in these situations, and that’s why virtually every system starts like this.” This asserts the “two-pizza team” rule by Amazon, which says that if a team responsible for one microservice couldn’t be fed with two pizzas, it is too big.
[box type=”shadow” align=”” class=”” width=””]”As business and teams grow, they need better coordination. Developers start stepping into each other’s toes often. Knowing the intent of a particular piece of code is trickier. Migrating then makes sense to give some separation of function and clarity. Each team can set its own objectives and work mostly on their own, presenting a clear external interface. But for this to make sense, there should be a critical mass of developers,” he adds.[/box]
Best practices to follow when migrating to microservices
When asked about what best practices developers can practice when migrating to microservices, Buelta said, “The key to a successful microservice architecture is that each service is as independent as possible.”
A question that arises here is ‘how can you make the services independent?’ “The best way to discover the interdependence of system is to think in terms of new features: “If there’s a new feature, can it be implemented by changing a single service? What kind of features are the ones that will require coordination of several microservices? Are they common requests, or are they rare? No design will be perfect, but at least will help make informed decisions,” explains Buelta.
Buelta advises doing it right instead of doing it twice. “Once the migration is done, making changes on the boundaries of the microservices is difficult. It’s worth to invest time into the initial phase of the project,” he adds.
Migrating from one architectural pattern to another is a big change. We asked what challenges he and his team faced during the process, to which he said,
[box type=”shadow” align=”” class=”” width=””]”The most difficult challenge is actually people. They tend to be underestimated, but moving into microservices is actually changing the way people work. Not an easy task![/box]
He adds, “I’ve faced some of these problems like having to give enough training and support for developers. Especially, explaining the rationale behind some of the changes. This helps developers understand the whys of the change they find so frustrating.
For example, a common complaint moving from a monolith is to have to coordinate deployments that used to be a single monolith release. This needs more thought to ensure backward compatibility and minimize risk. This sometimes is not immediately obvious, and needs to be explained.”
On choosing Docker, Kubernetes, and Python as his technology stack
We asked Buelta what technologies he prefers for implementing microservices. For language his answer was simple: “Python is a very natural choice for me. It’s my favorite programming language!”
He adds, “It’s very well suited for the task. Not only is it readable and easy to use, but it also has ample support for web development. On top of that, it has a vibrant ecosystem of third-party modules for any conceivable demand. These demands include connecting to other systems like databases, external APIs, etc.”
Docker is often touted as one of the most important tools when it comes to microservices. Buelta explained why, “Docker allows to encapsulate and replicate the application in a convenient standard package. This reduces uncertainty and environment complexity. It simplifies greatly the move from development to production for applications. It also helps in reducing hardware utilization. You can fit multiple containers with different environments, even different operative systems, in the same physical box or virtual machine.”
For Kubernetes, he said, “Finally, Kubernetes allows us to deploy multiple Docker containers working in a coordinated fashion. It forces you to think in a clustered way, keeping the production environment in mind. It also allows us to define the cluster using code, so new deployments or configuration changes are defined in files. All this enables techniques like GitOps, which I described in the book, storing the full configuration in source control. This makes any change in a specific and reversible way, as they are regular git merges. It also makes recovering or duplicating infrastructure from scratch easy.”
“There is a bit of a learning curve involved in Docker and Kubernetes, but it’s totally worth it. Both are very powerful tools. And they encourage you to work in a way that’s suited for avoiding downfalls in production,” he shared.
On multilingual microservices
Microservices allow you to use diverse technologies as each microservice ideally is handled by an independent team.
Buelta shared his opinion regarding multilingual microservices, “Multilingual microservices are great! That’s one of its greatest advantages. A typical example of this is to migrate legacy code written in some language to another. A microservice can replace another that exposes the same external interface. All while being completely different internally. I’ve done migrations from old PHP apps to replace them with Python apps, for example.” He adds, “As an organization, working with two or more frameworks at the same time can help understand better both of them, and when to use one or the other.”
Though using multilingual microservices is a great advantage, it can also increase the operational overhead. Buelta advises, “A balance needs to be stuck, though. It doesn’t make sense to use a different tool each time and not be able to share knowledge across teams. The specific numbers may depend on company size, but in general, more than two or three should require a good explanation of why there’s a new tool that needs to be introduced in the stack. Keeping tools at a reasonable level also helps to share knowledge and how to use them most effectively.”
About the author
Jaime Buelta has been a professional programmer and a full-time Python developer who has been exposed to a lot of different technologies over his career. He has developed software for a variety of fields and industries, including aerospace, networking and communications, industrial SCADA systems, video game online services, and financial services.
As part of these companies, he worked closely with various functional areas, such as marketing, management, sales, and game design, helping the companies achieve their goals. He is a strong proponent of automating everything and making computers do most of the heavy lifting so users can focus on the important stuff. He is currently living in Dublin, Ireland, and has been a regular speaker at PyCon Ireland.
Check out Buelta’s book, Hands-On Docker for Microservices with Python on PacktPub. In this book, you will learn how to build production-grade microservices as well as orchestrate a complex system of services using containers.
Follow Jaime Buelta on Twitter: @jaimebuelta.
Read Next
Yuri Shkuro on Observability challenges in microservices and cloud-native applications
