An increasingly common buzzword in cloud computing is microservices. Like a lot of things associated with cloud technologies, a precise definition is difficult to find -- and it can mean a lot of things to a lot of different people, depending on the context. Since this is a blog devoted to middleware issues, I want to define microservices within the context of that middle layer in computing, for application development.
A Definition
Microservices is an architectural approach for a software system. Meaning, it defines how individual services fit together and how those services are constructed (like, general constraints or best practices). What sets microservices apart from other architectural approaches is that it treats each service as a discrete and independent part of the architecture. That means that services themselves (within that system) have very clear definitions:
- A single, clear purpose
- Well-defined parameters
- Polyglot
One of the keys to a microservice is 'loose coupling' within the overall architecture. A service only really has to interact with a direct upstream service (where it consumes data) and its direct downstream service (which consumes the data it sends). The only connective tissue between services is the messaging service (which is itself a microservice). Communication is done with simple, standard protocols, like posting JSON or YAML data to a REST API. The underlying services could be written in entirely different languages or even be frequently replaced by different services. Even the content of the messages themselves can change or can cover a variety of languages and data formats. Microservices is an architecture, not a specific product or technology or language. It is the way you do something, not the thing that you are doing.
However, that approach to the software architecture has a ripple effect because it can influence other aspects of a software rollout. Microservices are frequently conflated with technologies like containers or with development processes like agile. Again, microservices architecture is neither a technology nor a process in and of itself. But the outcome of a microservices architecture is a set of choreographed services which are modular, lightweight, and decoupled from other services.
A contrast to other architecture styles could be its own post (and will be one day). For defining microservices, however, some idea of the two major software architectures can help show what microservices isn't.
Some software was designed (or, really, evolved) into a monolithic architectural style. All services are essentially features of the same product, and the relationships between those services could be tight. In some designs, those services were tightly coupled; in Java EE, there could be modular monoliths, where there were clear separations between tiers, but the the packaging was coupled.
That monolithic software could be very complex, millions of lines of code. Object-oriented programming, and object-oriented languages like Java, introduced some measure of modularity, to break up the code into saner (and reusable) chunks. But that modularity initially only applied to how the code was written. It was still compiled into a single package or a set of packages that were tightly associated with each other; services were subsumed into the greater whole.
The next step was to create services (or clusters of services) separately but with using a clearly defined, centralized schema. This is service-oriented architecture. The services are technically independent, but they used the same internal logic, so there wasn't much flexibility how any individual service could be designed or when it could be delivered -- it had to adhere to potentially brittle schema and any major changes could crash the entire architecture.
With microservices, the services (functionality) itself is independent. The only requirement is that the individual pieces can talk with each other. As an architecture, even the micro part of microservices can be defined according to the need of the overall infrastructure -- one design may have (for example) all monitoring-related functions could be defined in a single service while another may have separate monitoring, alerting, notification, and metering services.
Microservices and Process
One thing that a microservice architecture isn’t (necessarily) is a process like agile. You can obviously do agile programming on monolithic software or develop microservices using a waterfall process -- but there is an organic association between microservices and agile-style processes.
The natural constraints of monolithic and service-oriented architectures were reflected in common development approaches.
- All services had to be developed according to the same schedule and delivered at the same time.
- All services had to be updated or replaced at the same time.
- Any enhancements a single service required updating all services (even if there were no changes to those other services).
With that much complexity in the development process, any changes had to be well planned out in advance, all services had to be tested simultaneously, and rollouts had to be done in an atomic and controlled way.
That meant that, naturally, IT departments, software developers, and executives adopted long planning and testing cycles and infrequent updates to minimize risk to the system. This fits a waterfall style approach.
By moving to a microservice architecture, the risk to the overall system of updating a single service is reduced. Services no longer need to be developed simultaneously, nor released at the same time. It is simpler to release smaller changes or to add new functionality and to iterate through changes. This allows for more rapid development styles, like agile and continuous integration / continuous delivery.
Microservices and Technology
Another thing a microservice architecture isn’t (again, necessarily) is containerized. Containers are virtualized divisions in the kernel of the operating system. Each container is isolated from any other container, and the container only has available resources like libraries that it uses, making a container very lightweight.
Because a microservice is a single service and containers host a single application, it is easy to assume that they are directly related. But, again, a microservice is an architectural choice first, not a specific technology.
For application development, microservices are well-suited to run in containers, but they can also run effectively in any distributed system. This distributed system can be fatjars within the Java space or it could be containers (especially with orchestration systems like Kubernetes. It also could mean a modular application server like Red Hat JBoss Enterprise Application Platform which has distributed services. Distributing the system allows services to be placed on appropriate hardware (e.g., putting services with heavy loads on systems with high CPU and memory) and locating services near to consumers.
Fitting Architecture to Needs
A microservice architecture has a lot of advantages, especially by increasing the delivery cadence, potentially increasing both security and quality. It can provide more flexibility in languages across stacks. It can also introduce more operational agility, such as the ability to scale or move services independently.
It’s not a perfect system, though. While the code complexity for a single service may be reduced, the overall complexity of the design is increased because it is a distributed system. This also introduces complexity in processes by potentially siloing development teams. It can make it more difficult to design and implement massive changes to multiple services, even as incremental changes are easier. And some basic tasks like monitoring and logging -- which are centralized and relatively straightforward in monolithic architectures -- can be difficult in more distributed microservices.
A microservice architecture is a tool. The requirements of the software, the abilities and culture of your IT team, and the availability of related services are all considerations in whether a microservice architecture would be an effective tool for a specific situation.
À propos de l'auteur
Deon Ballard is a product marketing manager focusing on customer experience, adoption, and renewals for Red Hat Enterprise Linux. Red Hat Enterprise Linux is the foundation for open hybrid cloud. In previous roles at Red Hat, Ballard has been a technical writer, doc lead, and content strategist for technical documentation, specializing in security technologies such as NSS, LDAP, certificate management, and authentication / authorization, as well as cloud and management. She also wrote and edited the Middleware Blog for Red Hat and led portfolio solution marketing for integration and business automation.
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit