The emergence of microservices and containers is comparable in its significance, scope, and role in IT development to the breakthrough that quantum theory brought to physics. In essence, microservices represent a qualitative new combination of software development concepts, with a particular focus on mapping business needs—Domain Driven Design (DDD)—with the construction of service-oriented IT systems, where proven components are shared across multiple applications, commonly referred to as Service-Oriented Architecture (SOA). Moving away from monolithic applications and entering the world of microservices requires changes not only in software but also in IT infrastructure. Microservices and containerization – a new approach to infrastructure
Microservices and containers as a method for implementing microservices architecture appeared in 2012, thanks to the work of Adrian Cockcroft at Netflix
[i]. In turn, the arrival of Docker and Kubernetes on the market provided the necessary tools for creating and managing applications. Containers managed within a single platform simplify microservice communication, which facilitates the design and construction of efficient network architecture. In terms of security, containers isolate microservices and applications, which radically reduces the risk of threats spreading throughout the entire corporate IT infrastructure. Each microservice can be treated separately, scaling them and adjusting their performance to current business needs. Microservice orchestration tools also facilitate the automation of launching individual components, which enables the use of a “
blue-green deployment” approach to introducing changes in business software. However, a smooth transition from monolithic solutions to microservices, despite the undeniable appeal of the latter, requires a new and precise approach to the entire IT infrastructure. Communication between individual application elements requires special attention; as they operate independently, they can generate network latency, increased processing time, and general performance issues in more complex configurations. Of course, automation, agile methodologies, and a
Cloud Native DevOps approach can reduce the scale of the problem, but it is already clear that the entire IT infrastructure must be geared toward fully utilizing the greatest advantage of microservices: their exceptional performance. This dependence on infrastructure can be minimized. It is for this purpose that the Service Mesh network infrastructure model was developed—a network of interconnected, globally configured traffic proxies
proxy. Thanks to this, developers can focus on creating new functionalities without having to align all assumptions with infrastructure requirements. Public cloud providers offer Service Mesh for microservices on their platforms, such as Google Kubernetes Engine or Azure Kubernetes Service. It is also clearly visible in the cloud computing environment that scaling individual application functions independently is becoming easier.
When creating an application from microservices there is no need to be dependent on a single technology or provider; you can choose solutions that best fit specific applications and business needs. In general, microservices are perhaps best suited for utilizing serverless architecture, which in many applications allows for significant savings in infrastructure costs, especially in new projects.
Microservices and containerization, and technical debt
Technical debt arises when an organization uses suboptimal technical solutions to satisfy its business needs as quickly as possible. Most often, the result of such decisions is applications that hinder or prevent the realization of the company’s future goals and development. As is often the case, temporary fixes often become the most permanent component of an organization. More difficult cases involve situations where an existing key monolithic application is genuinely good, users know and like it, and above all, have become accustomed to it. Sometimes such systems operate continuously for over a decade, and those who knew their code and architecture have long since changed jobs, tools, and forgotten how things work. In such a situation, the technical debt is truly serious, and as a rule, one has to pay dearly to regain the ability to modify and develop such IT solutions. Even adapting an application to current operating system versions or new encryption protocols in web browsers may require not months, but years of work from experienced developers who know legacy platforms and have enough knowledge to reconstruct the application using microservices.
In organizations where hundreds or thousands of microservices may be running, the problem to solve becomes securing them against unauthorized access and managing their mutual communication. You can, of course, use methods of securing traffic between services based on mechanisms implemented in shared programming library code, but this generates additional work. In the Service Mesh approach, you can define at the microservice level which access methods specific clients can use and which can be used without restrictions. The environment itself enforces the security policy. Unlike monolithic applications, microservices create a dynamic, constantly changing environment that inherently generates risk. A well-designed and implemented microservice must be prepared for failure—not only its own but also that of its surroundings. Developers must anticipate various types of defensive mechanisms and ways to retry resource requests, but thanks to this, creating an application in a microservices architecture allows for increased overall reliability. The application will not fail even if one of its functions proves to be poorly designed or encounters unexpected problems. For more complex applications, it is possible to use the principles of continuous deployment and integration (CI/CD) –
Continuous Deployment –
Continuous Integration. Containers, in which microservice code runs, enable applications to operate by accessing the resources of the server’s operating system directly. Consequently, they start faster than virtual machines and ensure high performance while simultaneously lowering infrastructure operating costs. The chosen microservice orchestration platform is of great importance for achieving appropriate data processing performance. One must also not forget about the proper allocation and distribution of resources for mission-critical microservices. The categorization and prioritization of microservices within the ecosystem must correspond to their importance and value to the organization’s entire operation. Only then will all the advantages of microservices and containerization be revealed.
When is it worth using a microservices-based architecture?
Business application architecture built from microservices works best where new functionality needs to be created and added frequently. In monolithic systems, this requires finding the right place in the code, meeting intermediate interface requirements, or reaching the view layer, so the matter becomes complicated as code complexity grows. The remedy for this ailment is microservices—small programs with a communication interface. Microservices also appear where scalability is a problem. It has long been known that monolithic applications are difficult to scale because it usually requires costly scaling of the whole system. In a microservices-based architecture, you can focus on scaling only those services that have the highest loads, which reduces the costs of maintaining such an application. Thanks to microservices, an organization can overcome the limitations resulting from using a specific technology stack in monolithic applications, where it is sometimes very difficult to migrate to new versions of languages, libraries, or frameworks. At least in theory, each microservice can be written in a different programming language chosen depending on the task and the business process being handled. Therefore, it is possible to update microservice technologies without much difficulty, without worrying about breaking the entire system.
Advantages and disadvantages of microservices and containerization
An application built from microservices has an undeniable advantage over a classic monolithic design. This is primarily due to a significant reduction in the risk of stopping the entire system due to a minor error in one area
[ii]. The increase in the stability of such an application is accompanied by the ability to deploy new versions, test new functionalities, and study user reactions much faster and more frequently. Dividing a complex system into many easy-to-manage elements allows for independent scaling of each service and better control over the level of technical debt. Incidentally, each such element is easier to understand, design, and maintain on an ongoing basis. Psychological factors also count—the development team focuses only on the functionality of the microservice, choosing the technology and the way of implementing services themselves. Consequently, the construction and deployment of the application proceed more efficiently and quickly. Even if it turns out that a completed microservice needs to be thrown in the trash and rewritten, it does not involve high costs; it is only a small fragment of a large puzzle. Of course, nothing is perfect—microservices architecture and containerization are not profitable for small project deployments; they require a deep understanding of business specifics and excellent organization of work and communication between teams. A more complicated architecture and the presence of a network layer in communication between application components make testing and troubleshooting more difficult, especially when the analyzed process uses services from many microservices. Despite these imperfections, according to the “2022 Service Mesh Adoption Survey”
[iii] report, 85% of companies plan to rebuild their systems using microservices architecture, and 53% are already using
Kubernetes containers to handle at least half of their production workloads.
[i] https://bykowski.pl/mikroserwisy-wprowadzenie-i-praktyczny-przyklad/
[ii] https://itreseller.com.pl/mikroserwisy-idealne-rozwiazanie-na-wzrost-i-rozwoj-biznesu-dlaczego-wyszly-z-mody-monolityczne-pakiety-aplikacji/
[iii] https://www.solo.io/resources/report/2022-service-mesh-adoption-survey/
