Microservices not only helps software development but also form the basis for the DevOps approach. Increasingly complex IT environments are driving the spread of microservices architectures. What this is and what you should know about it. Applications consist of a variety of tasks, the execution of which the computer system divides among the available resources. One of the essential questions of software development: How should the individual pieces of code be linked to each other so that the application runs as efficiently and efficiently as possible? An increasingly popular answer to this question is that; microservices consist of small, separate and functional pieces of code that interact with other microservices, thus forming a larger application system.
Even if the basic idea of individual, separate functional components is nothing new, the way microservices are implemented makes it the foundation for modern cloud applications. In addition, microservices are also closely intertwined with the DevOps approach, which aims to deliver new features quickly and continuously.
What are microservices?
The “micro” in microservices implies that they are exclusively small applications. This is correct in some cases – but not in others: microservices should be just as large as they need to be to solve a specific issue or problem – say the proponents of this architectural system. However, the underlying problem should be a conceptual one, not a technical one.
---
Microservices should not be around horizontal layers like Data Access or messaging, but be built around business potential. Microservices interact with other microservices and external users through interfaces (APIs)to form a larger application.
Therefore, the individual functionalities of a microservice can be adapted or revised comparatively easily without affecting the rest of the system. This, in turn, contributes to the DevOps approach: when the specific functions of a larger application are split into separate, independently functioning pieces of code, it is much easier to put the mantra of continuous integration and delivery into practice. Standardized APIs help to make microservices easy to test automatically.
Microservice architecture or monoliths?
If you hear about microservices, it’s mostly related to software architectures. Microservices architectures include not only the microservices themselves but also management and service discovery components, as well as an API gateway that is used for the communication between the microservices and the outside world.
A monolithic application represents the alternative to microservices. It describes an application whose program code consists of a single, huge binary file. A monolithic application is therefore much harder to scale and optimize. However, because the functions are hardwired and integrated, such an application monolith usually causes less management effort than a microservices architecture.
How to define microservice?
Microservices should represent a specific function – at least in theory, this is easy to say. In practice, the network of relationships between the individual functionalities of an application is in most cases so complex that a clear demarcation is more difficult than one might think. Domain analysis and domain-driven design are the theoretical approaches that help you break down your task into individual problems that microservices architecture can solve with a view to the big picture.
What distinguishes microservices from SOA and web services?
The idea of having small individual programs work together is reminiscent of both SOA (service-oriented architecture) and web services – both buzzwords from the venerable Web 2.0 era at the beginning of the 2000s. Even if microservices don’t reinvent the wheel, there are some fundamental differences between SOA and Web Services. Here you will find a detailed explanation of the individual architectural models – in the following the short version:
Within an SOA, the individual components are relatively closely linked and access certain assets such as storage in parallel. The communication between the components runs via a special middleware software, a so-called enterprise storage bus. By comparison, microservices are more independent, less resource-intensive, and communicate via leaner protocols. It is worth mentioning that microservices were created in the haze of SOA and are partly seen as a successor concept to the service-oriented architecture. A web service maps a publicly accessible set of functions that other applications can access via the web.
How microservices and containers are linked?
Of all the technologies that form the basis for microservices, containers have made it the furthest into the business IT mainstream. A container is similar to a virtual machine (VM), but is just an isolated user-space that uses the kernel of the operating system while it’s internal computing operations run independently. Containers are much smaller than VM instances and are easier to roll out – both locally and in the cloud.
Why containers and microservices harmonize well is obvious: each microservice can run in its container, which drastically reduces the overhead in terms of service management. Most container implementations have various tools that can be used to deploy, manage, can automatically control scaling, networking and availability of container-based applications. The combination of small, easy-to-develop microservices and easy-to-roll out containers makes the DevOps approach possible in the first place. There are various implementations of the container concept, of which Docker is by far the most popular.
Container-based systems are also versatile: within a container, any programming language supported by the operating system can run. This gives software developers much more flexibility. In general, it is a major advantage of microservices that each service can be written in its programming language – depending on which one makes the most sense for the developer. It would even be possible to develop a single service entirely in a new programming language without affecting the system in its entirety – as long as the APIs remain stable.
