Takeoff
Published in

Takeoff

Strategic Success with Microservices

A microservices architecture is a new architectural style for creating loosely coupled but autonomous services. New technology trends — such as DevOps, Platform-as-a-Service (PaaS), Container, Continuous Integration and Continuous Delivery (CI/CD) — enable companies to develop and manage these modular systems on an unprecedented scale that outshines previous approaches such as SOA. But the success of companies refactoring monolithic applications into microservices varies widely. The prerequisite for effective use of microservices is a solid understanding of how and why companies should use microservices to build applications.

A microservices architecture is a new architectural style for creating loosely coupled but autonomous services. New technology trends — such as DevOps, Platform-as-a-Service (PaaS), Container, Continuous Integration and Continuous Delivery (CI/CD) — enable companies to develop and manage these modular systems on an unprecedented scale that outshines previous approaches such as SOA. But the success of companies refactoring monolithic applications into microservices varies widely. The prerequisite for effective use of microservices is a solid understanding of how and why companies should use microservices to build applications.

Improvement of SOA

A service-oriented architecture (SOA) is typically defined as a collection of application components that communicate with each other to provide services to other components over a network. The goal of an SOA was to develop robust distributed applications without complex centralized components.

In addition, an SOA was closely linked to the organizational structures and was used to support new internal structures. For this reason, its success depended heavily on the restructured organizational capabilities and the building of the teams that designed the architecture. Instead of creating loosely coupled but autonomous systems, an SOA led to highly fragile systems that relied on a complex infrastructure. In addition, early SOA deployments were accompanied by vendor lock-in, as proprietary middleware was often geared to centralized logic, persistence, governance, and administration.

Microservices architectures are increasingly delivering on the promises of SOA at every stage of application development, from development to deployment to operations. A microservices architecture is designed to simplify the technology to create complex systems with optimized components. A centralized logic and integration infrastructure based on heavyweight, non-standard platforms are replaced by communication over simple, standardized connections based on asynchronous HTTP or messaging protocols. SOAP, XML, and other heavyweight protocols and data formats are replaced by the lean JSON over an HTTP-based REST interface. Each microservice has its own data store; centralized governance and persistence are not required.

Microservices use Continuous Integration (CI) and Continuous Delivery (CD) methodologies and practices, as well as some key components that were less common in an SOA. These include

  • Multilingual programming and persistence
  • Container or Invariant Virtual Machine (VM)
  • Flexible, Programmable Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS)

Innovative solution for a flexible, fast-reacting environment

Faster delivery

Microservices have a smaller scope because the focus is on domain boundaries and unified domain modeling and require less code. Deployment strategies such as focused, standalone archives — often packaged as Linux containers — and CI/CD lead to faster, more reliable deployment. As a result, the software development cycle is generally accelerated. New features and bug fixes, as well as fully tested security patches, are delivered faster.

Modular control

When using Microservices, each service can be individually scaled to accommodate temporary or seasonal traffic growth, batch processing, or other operational requirements. Better fault isolation ensures that service issues such as memory leaks or open database connections only affect the service in question. The scalability of microservices complements the flexibility of cloud services to improve service and serve more customers simultaneously without service interruptions.

More choices

The microservices market is driven by open source technology solutions and organizational practices. As a result, microservices reduce vendor lock-in and prevent long-term technology lock-in. So you can choose the tools you need to achieve your IT and business goals.

Creation of a solid foundation for microservices

To successfully deploy microservices, companies must first create a solid foundation for their monolithic architecture. To take full advantage of microservices, you need to consider modularity, domain boundaries, and the fundamentals of distributed system theory.

In addition, more complex systems benefit most from microservices. Although each service is completely independent, certain operational requirements must be met. These include

  • DevOps
  • PaaS
  • Container or Invariant VM
  • Replication, registration and detection of services
  • Proactive monitoring and alerts

Because meeting these requirements can mean a significant investment with no immediate return, Microservices may not be a cost-effective solution for every team or project. A “monolith first” approach ensures that application development is based on solid design principles and domain boundaries are properly defined. On this basis, you can gradually move to a microservices architecture if scalability requires it. For example, a simple shopping cart application should have the following characteristics:

  • Separation of Concerns
  • Strong cohesion and low linking through well-defined programming interfaces (APIs)
  • Separate interfaces, APIs and implementations according to the Demeter Law, also known as Law of Demeter (LoD).
  • Domain-driven design for grouping related objects

After a monolithic application to be scaled has been developed according to the principles of the software architecture, a refactoring in Microservices can take place. The most effective refactoring method consists of the following steps:

  1. Identify business boundaries and semantic differences in the application domain and decompose each domain into its own microservices.
  2. Find the component that is most often changed on request — such as updates to business rules related to pricing or regulatory changes — or for which patches are often deployed to close security holes.
  3. Once the basic domain-based microservices have been defined, the APIs used for service interaction must be customized. You can use aggregate, proxy, chain, event, or other design patterns to design these APIs.

Coordinated, competent teams

The success of a microservices architecture does not depend on the technology, but on the organizational structure of a company. This requires flexible and autonomous teams with a flat organizational structure and cross-functional competencies.

In order to create an effective, competent team, employees must be reoriented towards functionality rather than architecture. One example is Amazon’s small mobile teams of 8 to 10 employees (also known as “two-pizza teams”) who are responsible for the development and maintenance of the service. Conway’s law states that companies can only create designs that reflect their organizational structure. If teams are subdivided into different tasks, such as development, operations, quality assurance and security, there is limited flexibility and delays.

By implementing DevOps and defining communication strategies before switching to Microservices, these problems can be avoided or mitigated. It also prevents the creation of a failed SOA instead of an effective microservices architecture.

Data management

Another important aspect to consider when migrating to microservices is data management. Unlike SOA, Microservices does not share data. Rather, each microservice has a separate physical data store and multilingual persistence that allows different database engines to run for each microservice. This makes it possible to select an individual data store for each service instead of storing all data in an enterprise-wide relational database management system (RDBMS).

However, maintaining multiple versions of an enterprise database can increase licensing costs and complexity. In addition, data storage often needs to be aligned for consistency. Generic ETL (Extract, Transform, Load) or data virtualization tools can support data normalization. Event sourcing, on the other hand, is a common design pattern for adapting data stores to subsequent changes.

Conclusion

A microservices architecture can offer companies many benefits — from independent scalability of individual application components to faster, easier software development and maintenance. But microservices are not necessarily beneficial to every team or project and can represent a significant investment with no immediate return on investment. The transition to microservices should be done gradually. Instead of a complete migration, refactoring can also be beneficial for parts of existing applications. To successfully deploy Microservices, organizations must first build a well-designed application that meets existing platform standards. They should then refactor the application into a set of microservices to meet business requirements. With the right people, processes and tools, microservices can accelerate development and deployment, simplify maintenance, improve scalability and prevent long-term technology lock-in.

For more information feel free to check out sdev-software.com or use the shortcut sojourner.dev

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marcus Ziegler

Marcus Ziegler

CEO of Sojourner Development. I am a dedicated software engineer, coder, software security expert and designer. In my spare time I am a hobby photographer.