Welcome!

Microservices Expo Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Andreas Grabner

Related Topics: Microservices Expo, @CloudExpo, @DevOpsSummit

Microservices Expo: Blog Feed Post

Microservices, Service Registries, and Architectural Debt | @DevOpsSummit #DevOps #Microservices

Microservices is not just a style of application development, it’s a set of design principles

Microservices is not just a style of application development, it’s a set of design principles guiding how applications are composed (or decomposed, as the case may be) with a resulting architectural shift as supporting components are added to the mix. Much in the same way SOA brought us UDDI registries and gateways, microservices is bringing service registries.

Service registries, for the uninitiated, are kind of like the internal DNS of a microservices environment. They’re needed to manage the rapid association and disassociation with IP addresses of the containers in which the microservices are typically (but not always) hosted. The average lifespan of a container is measured in minutes or hours, perhaps a day or two, but rarely weeks, months, and probably never years. That means a state of nearly constant change with respect to the infrastructure supporting those services, like the network and app services.

The service registry is responsible for managing that change; it’s where IP addresses and service instances are matched up and handed out to clients (in a client-side architectural pattern) or load balancers (in a server-side architectural pattern). It’s maintained through automation; manual methods of managing the change would simply be too slow and expensive in an environment where new mappings might occur by the minute, hour, or even on a daily basis.

It is here that we return to the imperative that is managing architectural debt. While you can’t eliminate it any more than you can eliminate the technical debt incurred by choices at the code layer, you can manage and try to minimize it. Careful attention to how these new, supporting components are selected and implemented is critical to that endeavor. Each option (client-side, server-side) brings with it a certain amount of architectural debt that will need to be paid in the future.

Introduction of an external service registry necessarily introduces a dependency that cannot be ignored. With a client-side registry, the client is tightly coupled to the registry. Code in the app is required to maintain that dependency and thus impacts the overall development lifecycle. With both patterns, the application will not be able to function without the service registry. This is because without it there’s no way to properly direct the client to an instance of the microservice for processing. Like DNS, the service registry is the glue that loosely binds clients and the “app”.

Thus additional precautions may be required to ensure availability of the service registry, such as the deployment of a high availability (HA) architecture. Because an HA architecture relies on redundancy, this means there must be at least two service registry instances running. This can further complicate the server-side architecture because both instances must be updated whenever an instance is launched or terminated.architectural debt service registries

This is architectural debt, in which choices made require specific architectures that must be maintained over time and incur operational overhead, and is often difficult to change in the future.  This is increasingly true as app-centric (affine) services like load balancing migrate into the application architecture rather than simply co-existing “nearby” in the network. As these critical services (scale is inarguably critical today) are integrated into operational systems that are code-driven, automated, and orchestrated they become as vulnerable to incurring debt as any other code-bound counterpart. Simply shifting from an external server-side service registry to the use of the load balancer’s innate ability to act as a service registry requires payment of the architectural debt incurred from the original decision and further, in an automated, software-driven environment, also requires payment of the technical debt you incurred to integrate with the external service registry. .

It’s important to remember that microservices impacts not just development, but deployment, too, and the architectures required to support delivering their services to the users (people, things, and apps). This is not as simple a change as migrating from Apache to IIS (or vice versa). It’s a disruptive change to the architecture, and that will necessitate a certain amount of architectural debt stemming from the choices you make early on in the adoption cycle.

Architectural debt can be minimized, but not mitigated entirely. Therefore it’s important to start evaluating options now, before hasty decisions are made that will later be regretted or cause unforeseen costs or complications.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Microservices Articles
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will deployment. Storage, for instance, is more capable than where we read and write data. In his session at @DevOpsSummit at 20th Cloud Expo, Josh Atwell, a Developer Advocate for NetApp, will discuss the role and value...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace....
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
SYS-CON Events announced today the Kubernetes and Google Container Engine Workshop, being held November 3, 2016, in conjunction with @DevOpsSummit at 19th Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA. This workshop led by Sebastian Scheele introduces participants to Kubernetes and Google Container Engine (GKE). Through a combination of instructor-led presentations, demonstrations, and hands-on labs, students learn the key concepts and practices for deploying and maintainin...