The Hype and Hope of Microservices: A Presentation by John De Goes

Between Business & Tech. Episode 1: Miroservices

Scalac invited John De Goes, the founder of tech consultancy, training, and development company Ziverge, and creator of ZIO to present his views on microservices at its “Between Business & Tech” conference. 

The digital event platformed six speakers with real-world experience of leveraging microservices to improve business outcomes for clients. Follow this link to watch John’s talk and see other videos from the whole conference.

John is a software engineer with a history in mathematics and over twenty-five years of experience writing software. He has contributed to a wide range of open-source projects for functional programming languages and has written multiple books on development topics. 

In his presentation, John contrasted the hype and benefits of microservices architecture with the actual reality of implementing dedicated microservices architecture in a corporate context. First, John addressed how the hype around microservices arose because of the challenges associated with building monolithic systems.

He then explored several key topics in turn: what microservices are, why they are important, what problems they solve, and the reality of executing a microservice infrastructure. 

Lastly, he shared his views on the future of microservices and spoke about several tools that aid developers in creating effective microservice-based architecture, and thus constitute a source of “hope” for the future. 

What Are Monoliths?

John began his presentation by detailing the problems with monolithic applications. The size and pervasiveness of these problems caused a significant amount of hype when microservices were introduced as a potential solution. 

Monolithic architectures bundle all application functionality into a single unit that developers package, deploy, and run. In a monolithic architecture, only the “edge” of the application acts as the user-facing service, while the rest of the application is made up of code. 

Diagram of a monolithic architecture.

John shared some notable advantages of monolithic applications. They have lower overheads because developers can use ordinary code that is stored as one unit, possibly even in the same repository. In addition, single-unit architecture facilitates rapid application development.

However, he noted that monoliths have several serious drawbacks:

• Maintenance: When developers change part of an application’s functionality, they must also modify all other app features that interact with the initial section of code. As a result, updates must be made concurrently. Such an approach constitutes a significant maintenance burden and typically requires multiple developers who must update different parts of the application in unison. 
• Deployment: The nature of monolithic applications causes deployment problems. When developers want to deploy a component, they must deploy it as a whole even if some features aren’t ready. Using pull requests and delaying pull requests that are merging can resolve deployment concerns to an extent. However, these solutions lead to other problems, such as feature freezes on stable branches of the application and increased overheads.
• Infrastructure: A significant problem with monolithic infrastructure is that different application components have their own specific requirements. For example, the search component of an app may use the analytics tool Elasticsearch, while the transactional email component may rely on Amazon’s Simple Email Service. Alternatively, some application parts may be central processing unit (CPU) intensive while other parts require large amounts of memory. Due to a monolith’s single-unit structure, the requirements of each disparate element must be applied to the whole application. This leads to significant inefficiencies. 

• Encapsulation: Encapsulation is the bundling of connected data and methods into one unit that is restricted from other functionality. Monoliths don’t support encapsulation because all application parts have direct database access. Therefore, any developer can initiate a Structured Query Language (SQL) update to change functionality in a way that goes against a business’ rules. As a result, John has found that enforcing business logic in a uniform way across a gigantic monolith application is extremely difficult. Development teams end up relying on unreliable, difficult-to-scale methods like convention, discipline, skill, and training to maintain business logic consistently.
• Failure scenarios and bugs: One common type of failure scenario occurs when a bug becomes evident in a component. These types of bugs are often severe and affect the whole application. For example, if the search functionality of an app has a memory leak, all components are compromised because everything in a monolithic system is bundled together. These kinds of systems lack resilience and leave developers unable to deal with errors quickly and effectively. 

To summarise

John concluded that lean development should prioritize efficiency and reduce waste. Monoliths are “anti-lean” because they tie application parts together into one unit. This significantly increases the amount of work in progress on the part of developers. Application updates are often left in pull requests and remain unused by the end-user. 

What’s more, monoliths are strongly coupled architecturally, which increases process variation. “Process variation” refers to the absence of a pattern among application processes. High levels of process variation combined with significant amounts of work in progress can be catastrophic and result in unshipped features and significant downtime. This can leave development teams unable to schedule and deliver work, which in turn can considerably impact business performance. 

John stated that development teams that are unable to ship updates quickly would struggle to implement feedback in a timely manner. Businesses with slow-learning teams are at risk of being out-performed by other companies, especially in competitive industries. 

John observed that Fortune 500 companies like Amazon and Netflix dominate their sectors because they are highly effective, agile, and boast a lean development style that can put competing companies out of business. Therefore, companies must take their architecture and best-practice implementations very seriously.

Are Microservices Over-Hyped?

After highlighting the issues associated with monoliths, John turned his attention to the hype surrounding microservices. 

Microservices are a newer style of architecture designed to solve the problems created by monolithic structures. Rather than a gigantic monolith that packages everything together, microservices divide an application into multiple “pieces.” Each microservice is packaged, developed, maintained, deployed, upgraded, and versioned independently.

Diagram of a microservices-based architecture.

John outlined the specifics of what a microservice architecture can deliver:

• Maintenance: Development teams can update components in isolation which streamlines maintenance. For example, a change to, say, an app’s subscription functionality only requires an update or new issue of that component. 
• Deployment: The process of deployment is not only simplified but safer because developers can deploy components individually. A development team can optimize each microservice to fit its functionality needs, meeting specifications for CPU, RAM, and the number of nodes. Furthermore, each service can be fitted with database and search instruments such as separately.
• Encapsulation: Even though microservice architecture doesn’t mandate encapsulation, it makes it more straightforward to enforce. For example, a development team may stipulate that user account details in a database can only be accessed through the user account service. This makes applying business logic easier for developers. 
• Decoupling: Microservices are lean and have a decoupled architecture. This significantly decreases work in progress and minimizes process variation. Decoupled systems enable businesses to deliver value to users and learn from and implement feedback quickly. 
• Shipment: Shipment is quick and isolated with microservices. It’s not uncommon for new developers to ship features on their first day on the job.

Microservices: the Reality vs. the Hype

After covering the benefits of microservices architecture, John turned his attention to some of the drawbacks. While microservices do deliver on many of the promises previously described, there are also several crucial caveats.

A slide from Daniel Woody’s talk on microservices showing the experience many developers have when building their first microservice-based architecture.

Often, teams building their first microservice application create disordered architecture. The complexity of implementing microservices has even resulted in some developers pushing back against their use.

John acknowledged that it’s important to recognize both the benefits of microservices architecture and the challenges of executing microservice applications.

Let’s take a look at some of the drawbacks:

• Discovery: When microservices locate each other, this process is called “discovery.” Microservices that make up apps are discrete units and, as such, discovery can often be tricky. 
• Security: Creating a secure microservice-based system is challenging. Monolith applications run mostly in a trusted environment. Within a microservice-based architecture, however, it’s difficult for one service to check if it can trust another. There are several authentication mechanisms to certify service legitimacy. However, their implementation requires resources, computer space, and code.
• Monitoring: Developers must closely monitor microservice architectures because there are numerous moving pieces. Development teams need detailed metrics to track how services are functioning. This enables them to identify and respond to problems during the deployment process effectively. As a result, developers implement logging, especially an advanced type of logging called distributed tracing. Distributed tracing succeeds in keeping track of multiple parts of information moving through services. However, it also adds significant complexity to applications.
• Recovery: Recovery and failure scenarios must be considered by development teams. When a catalog fails, developers need to know how to restore it. In addition, services are often dependent on one another for functioning, meaning that the failure of one service can create problems for other application parts. 
• Routing: It’s not uncommon for many different nodes to run a single service. Because of this, developers must create a system that routes requests to nodes evenly. 
• Deployment: In a monolithic structure, there is only one unit to ship out and scale. In contrast, microservice developers deploy architecture on a variable number of nodes that may not be connected. Some services might be deployed on two nodes, while others may require thousands. What’s more, development teams must also consider versioning differences when deploying microservices.
• Load balancing: Development teams must balance requests between nodes to prevent overloading and maintain steady traffic. For example, if a request comes into a microservice that deals with fraud detection within an app, it is essential that the load is balanced and no single node is overloaded.
• Traffic control: Often development teams want to impose limits or policies to avoid traffic-related problems. However, when developers do add traffic control (or other similar features) to a service, it creates additional work and complexity.

The Hope of Microservices

Despite the challenges associated with microservices, John believes there is hope that businesses of all sizes can implement effective microservice-based architectures.

For the final part of his presentation, John outlined some of the best tools for creating successful architectures. He said that they should give developers hope for the future. 

Kubernetes 

Kubernetes is a fairly new technology. In many cases, it comes close to being an “operating system” for deploying and running cloud-native applications. 

Kubernetes is not explicitly designed for microservices. Consequently, it does not offer everything required to deploy microservice-based architecture. However, it provides a lot of the infrastructure necessary to deploy, operate, manage, and monitor microservice applications. 

Kubernetes’ popularity has encouraged many open-source projects, frameworks, and vendors to produce Kubernetes-compatible tooling. And this has led to the platform’s evolution.

John thinks that these advancements have turned Kubernetes into a crucial part of microservice-based development. Therefore, it’s essential that businesses build teams that are trained in and possess expertise in Kubernetes.

Kubernetes has an architecture similar to the one shown below:

A Kubernetes diagram.

Here is a list of the main Kubernetes features:

• Controls multiple cubelets, each of which has a proxy.

• Scheduler
• Functionality for monitoring and deploying
• Scalable 
• Executes restarts
• Assists with security
• Support discovery 

John said that Kubernetes solves a lot of the challenges associated with microservice application development. However, it does not resolve every single issue as it wasn’t designed as a platform specifically tailored for microservice-based apps. 

Service Meshes

To remedy some of the other issues with microservices that aren’t resolved by Kubernetes, developers often utilize service meshes. 

John posited that the top three service meshes available to build and deploy a microservice-based architecture on Kubernetes are Console, Linkard, and Istio. These three solutions all have structures similar to the one shown below, in which each microservice is deployed with a sidecar proxy.

A Sidecar Mesh diagram.

A sidecar is a proxy that acts as an envelope that encloses a microservice. Any communication with the microservice goes through the proxy. As a result, the sidecar has full insight into the microservices’ activity. 

Service meshes and sidecars provide various benefits, including the following:

• Help solve monitoring issues 
• Assist with recovery  
• Perform routing 
• Offer orchestrators, monitors, and supervisors that manage functionality

• Load balancing 
• Traffic control
• Enforce different policies  
• Help microservices discover each other 
• Perform security tasks

John asserted that service meshes represent high-quality technologies that cost-effectively offer features through Kubernetes.

Smart Microservice Frameworks

John also spoke about another exciting development: Kubernetes’ continual expansion of the types of functionality it offers. Kubernetes persistently incorporates features at the fringe of service mesh development. Moreover, frameworks like Spring Boot regularly add features, which makes it easier for developers to ship best-practice microservices.

John theorized that service meshes could well lose popularity and become more niche despite the solutions they offer. This is due to smart, next-generation microservice frameworks that consolidate different features into one package. What’s more, these features can deploy natively into Kubernetes, combining with Kubernetes’ functionality (that is constantly being optimized for microservice deployment).

Stateful Services

Some next-generation stateful functions (also known as stateful serverless or stateful workflow solutions) are designed to shift the way developers think about building distributed applications. 

Development teams can use stateful functions for more than just microservices. This is because they enable ordinary developers to focus on business logic rather than infrastructure or databases.

Stateful service technology is based on the concept of a computer that never goes down and maintains data persistently. John believes that this breakthrough class of solutions will likely alter how microservice-based architectures are built and deployed. Additionally, they could radically simplify infrastructure by offering developers a constrained environment. 

Open-Source Solutions 

There are many open-source solutions that developers can use to solve the challenges created by microservice architectures.

Training and Senior Experience

John believes that there’s no substitute for training developers, whether through books, workshops, or other means. In addition, expert developers with experience building and deploying successful, best-practice microservice architectures are incredibly valuable in ensuring project success. 

Third-Party Consultancy Services

Finally, consultancies, like Scalac and Ziverge, are available to help businesses. A consultancy provides extra support to ensure that clients have well-organized, cost-effective project timelines and development processes. Often, working with a consultancy is also much more cost-effective than hiring a professional in-house. 

Conclusion

Microservice-based architectures solve many of the issues created by monolithic systems. But implementation carries many challenges. 

Technologies like Kubernetes, service meshes, and smart microservice frameworks are crucial for making microservice development accessible to companies of all sizes. 

In an increasingly competitive marketplace, businesses also require well-trained developers and expert guidance to produce the best possible software outcomes.

Scalac has worked with a range of clients, from small companies to multinational enterprises. We also have experience with a wide assortment of different software types. 

If you’re thinking about engaging the help of a professional development company, in the process of building an outsourced team, or considering working with a consultancy service, get in touch with Scalac today to discuss your needs. 

See also presentations by other speakers at the Business & Tech Conference. Episode 1: Microservices

• Is Microservices Architecture the Silver Bullet? Mary Grygielski at Scalac’s Event
• Should Startups Be Using Microservices? A Presentation From Zuka Kakabadze
• How to Secure Microservices: A Presentation from Lukasz Marchewka

More microservices-related content

• What is Kubernetes, and why is the tech world going crazy about it?
• 6 COMPANIES PIONEERING THE USE OF DISTRIBUTED SYSTEMS
• Microservices
• How to Secure Microservices: A Presentation from Lukasz Marchewka
• 7 ZIO experts share why they choose ZIO