Applications consist of a large number of tasks, the execution of which the computer system distributes to the available resources. One of the key questions in software development: How should the individual pieces of code be linked to one another so that the application runs as efficiently and efficiently as possible? An increasingly popular answer to this question is microservices – small, separate and functional pieces of code that interact with other microservices and thus form a larger application system.
Even if the basic idea of individual, separate functional components is nothing new, the way in which microservices are implemented makes them the foundation for modern cloud applications. In addition, microservices are also closely interwoven with the DevOps approach, which aims to deliver new functions quickly and continuously.
What are microservices?
---
The “micro” in microservices implies that these are exclusively small applications. This is correct in some cases – but not in others: microservices should be exactly as big as they need to be able to solve a specific issue or problem – say the proponents of this architecture system. The underlying problem, however, should be conceptual and not technical.
Microservices should not be built around horizontal layers such as data access or messaging but around business potential. Microservices interact with other microservices and external users via interfaces (APIs) in order to develop a larger application.
Therefore, the individual functionalities of a microservice can be adjusted or revised comparatively easily without affecting the rest of the system. This in turn benefits the DevOps approach: If the specific functions of a larger application are broken down into separate, independently functioning code parts, it is much easier to put the DevOps mantra (continuous integration and delivery) into practice. Standardized APIs help make microservices easy to test automatically.
Microservice architecture or monoliths?
When you hear about microservices, it is mostly related to software architectures. Microservices architectures not only contain the microservices themselves, but also management and service discovery components as well as an API gateway that is responsible for communication between the microservices and the outside world.
A monolithic application represents the opposite of microservices. It describes an application whose program code consists of a single, huge binary file. A monolithic application is therefore much more difficult to scale and optimize. Because the functions are hard-wired and integrated, such an application monolith usually causes less management effort than a microservices architecture.
How do you define microservice?
Microservices should map 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 it is more difficult to clearly distinguish between them than you might think. Domain analysis and domain driven design are the theoretical approaches that help you break down your task with a view to the big picture into individual problems that microservices architecture can solve.
Each microservice should exist in a single bounded context, although some bounded contexts can also include more than one microservice.
What is the difference between microservices, 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. While microservices are not reinventing the wheel, there are some fundamental differences between SOA and web services.
Within an SOA, the individual components are relatively closely linked and access certain assets such as storage in parallel. Communication between the components takes place via special middleware software, a so-called Enterprise Storage Bus. In comparison, microservices are more independent, less resource-intensive and communicate using leaner protocols. It is worth mentioning that microservices emerged in the orbit of SOA and are sometimes seen as a successor concept to service-oriented architecture.
A web service represents a publicly accessible set of functions that other applications can access via the web. The most common example of this is Google Maps: If a restaurant owner wants to show his customers the way, he integrates maps on his website. This connection is far less rigid compared to microservices.
How do microservices communicate?
A clever piece of advice that you hear again and again when it comes to microservices is to rely on “smart endpoints and dumb pipes”. In other words: The goal with microservices should be to use the most basic and established communication methods possible, instead of complex ones with comprehensive integration. In general, communication between microservices should take place asynchronously. However, synchronous protocols such as HTTP can still be used, even if asynchronous protocols such as AMQP (Advanced Message Queuing Protocol) are now enjoying increasing popularity in the microservices environment. This type of loose connection makes a microservices architecture much more flexible – for example if individual components or parts of the network fail.
What do microservices have to do with Java?
Some of the first microservices achievements came from the Java community. As a result of these developments, a large number of Java frameworks emerged, based on which microservices can be implemented. One of the most popular is Spring Boot, which is specially designed for microservices. It is complemented by Spring Cloud, which – as the name suggests – brings such solutions to the cloud.
Of all the technologies that form the basis for microservices, containers have made it the furthest into the business IT mainstream. A container is basically similar to a virtual machine (VM), but basically only represents an isolated user space that uses the kernel of the operating system while its 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 bring with them various tools with which the deployment, management, scaling, networking and availability of container-based applications can be controlled automatically. The combination of small, easy-to-develop microservices and easy-to-roll-out containers makes the DevOps approach possible. There are various implementations of the container concept, of which Docker is by far the most popular.
Spring, on the other hand, is connected to the Java platform. Container-based systems are also versatile: any programming language supported by the operating system can run within a container. This gives software developers a lot more flexibility. In general, it is a major advantage of microservices that each service can be written in its programming language – depending on which 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 as a whole – as long as the APIs remain stable. At this point, you will find an interesting article that takes a detailed look at the advantages and disadvantages of Spring Cloud compared to Kubernetes.
How can be microservices designed?
Regardless of the language in which you develop your microservices, problem areas will arise that other developers have already worked on. In the field of microservices, too, there are therefore various design patterns that can be used to solve known, recurring problems in software development.
