Deutsch
Hurry, hurry, hurry – digitalisation is speeding up the world before our very eyes. As a result, companies have to develop and update their applications as quickly and efficiently as possible. This agile development is often simply too much for traditional, monolithic architectures, which is why there is now a demand for a flexible application architecture with microservices. Not only pure software projects benefit from this. Mist has also adopted the concept of microservices for network control and replaced the principle of monolithic network controllers with the microservice architecture. But what are microservices?
In most enterprises (with the exception of startups), the IT systems and business-critical applications have often been in use for a long time and are getting on in years. In most cases, these are self-developed systems that have been “uncontrollably” expanded over time with new functions and capacities. As a result, the architecture becomes more confusing, and modifications become more complex and expensive. These legacy applications are often built on monolithic architectures and a codebase that has grown over the years.
With these monolithically structured applications, it is not possible, for example, to scale an individual component to fit a new requirement; instead, a company has to supply more server capacity for the entire application. Code changes require extensive test cycles because they could impact another part of the application. The applications are therefore not flexible enough to evolve with changing market and customer requirements.
However, the situation is completely different with Amazon’s or Zalando’s successful webshops, for example. They integrate new functions or updates at least daily, sometimes even hourly – and are constantly developing their business model. They can do so because they deploy a flexible application architecture with microservices.
Microservices: flexible, scalable and independent
Microservices comprise loosely coupled, independent modules with self-contained functionality. A webshop, for example, then consists of various self-contained components for product search, product ratings, ordering or catalogue. In combination, these modules provide the overall functionality of an application via interfaces (APIs), or each implements a part of the web interface. Microservices are also suitable for modernising legacy applications by separating individual functions from the monolith and turning them into microservices so they can be scaled independently as needed. That makes enterprises more agile and more flexible.
Continuous delivery is replacing traditional software deployment in fixed release cycles and demanding a change in the way developers work. They are organised more in smaller teams and also have to handle operation as minor functional expansions of microservices have to go live quickly. In this way, automatic tests give them rapid feedback on possible errors while they are still working on programming.
Challenge: orchestrating the services
However, where there are advantages, there are also disadvantages. Altering the IT organisation to give more autonomy to developer teams can lead to friction losses. Microservices architecture also holds a number of challenges in store on a technical level. For example, the individual services have to work together to deliver the application’s functionality. Communication via networks adds further potential sources of errors. The complexity of services is shifted from the services themselves to the orchestration and coordination of the services – above all when you have a rising number of microservices and new functionalities.
With a microservice architecture, there can be hundreds or even thousands of small and heterogeneous systems to monitor. Special monitoring tools can help here. By means of status data and metrics, they reveal how individual services work together. Individual teams of developers can use this information to optimise microservices and better coordinate access to resources in order to avoid bottlenecks.
APIs are a key element in the integration of microservices. An API (application programming interface) can be used for the standardised exchange of information between an application and individual parts of a program and for the simplified connection of new channels or additional offerings.
Containers as a technical basis for microservices
Linux containers such as Docker play a key role in microservices architecture. They encapsulate and isolate applications/microservices with all required components such as libraries or scripts in an enclosed packet. Encapsulation prevents conflicts between applications as they would otherwise have to access central components of the underlying host operating system.
Being packed in a container also makes the applications more portable. They can be transferred without modification and installation to development, test, production or cloud environments, where they can then be run. This means that a wide range of different applications can exist in parallel on one system; applications and infrastructure are clearly separated regardless of whether physical hardware, virtual environments (Hypervisor) or a private, public or hybrid cloud is used for deployment.
Microservices architecture at Mist
Our partner Mist also uses a modular system with microservices when establishing wireless networks, thus enabling the company to dispense with the traditional hardware controller. The latter is often used to run error-prone and complicated monolithic firmware. Newer cloud-based wireless systems also rely on all-encompassing firmware for administrative purposes, the difference being that it now runs on software controllers. The disadvantages of this approach are long development cycles for updates and features as well as vulnerability to software bugs. In contrast to this approach, Mist uses microservices rather than conventional, uniform firmware for administration via the cloud.
The firmware has been split into functions, which now act independently of one another in the form of microservices. All microservices are connected via a real-time bus, which is responsible for modules’ communication with one another. The Mist cloud monitors all modules and scales the various services as required. Each service is supported by a dedicated developer team and is completely autonomous. Here you will find further information on microservices architecture from Mist. The modular system is also continued in the cloud services, which are also completely independent.
The microservices concept not only results in an agile and scalable network architecture. It also paves the way for a separation of hardware and software to enable a true Intent-Based Network (IBN).
Questions?
Just ask!
I am Sebastian Wiedemann from the HCD sales team. I will be happy to advise you or assist you with any questions. You can phone me on +41 58 590 110-0 or reach me using our contact form.
Contact us