Has your business ever implemented a big, new software solution that was supposed to solve all kinds of operational problems and provide you with big competitive advantages? And for those of you who answered yes, how many of you experienced a bumpy ride getting that solution up and running properly without any major crashes, training issues, or application changes that took months to come to fruition? While all of that was going on, did you lose any opportunities? In “tech years”, a lot of businesses remember experiences like this all too well, which can make decision-makers leery of “new solutions” over older, tried-and-true ways of doing things. The problem is that the world is moving ahead at dizzying speed. Companies that lumber forward with the speed of skeptical elephants will not be able to keep up with the limber, agile monkeys swinging from the new opportunities that advancing technology is making possible. 

The good news for the skeptical elephants out there is that new “microservices architecture” is eliminating the older issues inherent in implementing huge, monolithic software applications of the past. In fact, microservices can help elephants sprout wings and fly, but only when they adapt their company culture and communication systems to enable that type of growth. It’s definitely possible. So read on, and consider the possibilities of microservices in your organization.  

What Are Microservices? An Overview:

Microservices are a type of application architecture that overturns years of software development thinking. Previously, monolithic applications involved creating massive, complicated applications with millions of lines of code that do a hundred different functions. With microservices, each piece of functionality is its own independent, focused “microservice” that may only comprise a few lines of code. That by no means limits their usefulness, but it does give laser focus to their purpose. Several microservices can be connected together using APIs. Each microservice operates on its own, uses whatever language the developers chose, and can be quickly and easily scaled up or down for the end user’s needs. 

Microservices work on the principle of light, fast, agile “containers” or “virtual machines”. Each microservice does one thing, and does it very well and efficiently. If an application relies on APIs to connect microservices into a larger interface, the potential failure of one microservice will not cause the entire app to fail as it very well might in a heavy, traditional, monolithic software architecture. This makes updates and repairs quicker and easier while ensuring that the rest of the app continues to function without interruption, even while one microservice within the app is being updated. 

Why are Microservices so appealing?

Ultra successful enterprises have been using microservices in their day-to-day businesses for a while now. For example, Amazon whips out code updates literally every second of every day. The fact that millions of people use their services through all of these updates is a testament to how well microservices work. Netflix does daily updates with each change taking about 16 minutes to implement. 

Microservices empower companies in ways that monolithic app architectures can’t handle. For a company to provide in-demand, agile services, they need the more granular, modular, customizable application architecture of microservices. Some of the problems you might have experienced with monolithic architecture in your apps include: 

  • Difficulty with scalability. Monolithic apps are often so complex that it can take months to scale up or down, whereas microservices make it possible to scale up or down in minutes. 
  • Speaking of months, top-heavy monolithic have a long, slow development, implementation, and change cycle because so much code is involved and connected to so many other code pieces.
  • Changes in monolithic applications are labor-intensive, requiring a lot of time and effort from many groups, which may or may not communicate well with each other. (More on communication later.)
  • Monolithic applications are rife with security issues; the more complex and code-heavy the service, the bigger surface area is available to attach from bad actors. 
  • Taking all of these things into account, a large, cumbersome application of this type can be challenging to manage, which can blunt your company’s ability to act quickly and efficiently to changing circumstances and opportunities. 

Microservice architecture effectively removes these obstacles and replaces them with a much more agile, adaptable system that can move and grow with your needs and help you take advantage of more opportunities. 

Why Microservice Architecture Works

The move to microservice architecture brings together the best-in-show of application design principles. With a well-distributed microservice architecture that easily scales and adapts, updates, new services, and repairs can go live without bringing down the entire system. That’s why innovators like Amazon and Netflix can introduce so many updates and changes during the day without users even noticing. Let’s discuss some of the ways that architecture works by showing you how the Spark Equation engineering team works with microservices.

Run Microservices from Containers

Microservices run best from what we callcontainers, which are fast, light virtual machines that can spring from the same hardware. The application and its environment should be the only things running in each container. This runtime environment makes it easy for developers to implement changes and QA to run testing quickly, which leads to smoother, lighter deployment experience. 

How Spark Equation Builds Microservices

The Spark Equation engineering team has innovated and built a rational, smooth, agile microservice architecture of its own, which we then use to help others do the same for their business needs. The basic process below can help your organization make the cultural shift towards successful microservices implementation too: 

  • Define the domain scope for each microservice clearly and correctly. Remember: each microservice needs to be laser-focused on doing one service or function very well and efficiently. 
  • Orchestrate the decentralization of data management. This helps balance the data load with different, decentralized endpoints contained within the registry, which is part of the service. 
  • Standardize and automate deployment. We create a standard model for each microservice deployment and update that follows a systemic protocol that creates maximum agility. 
  • Ensure effective interaction of microservices at the network level using Service Mesh. This ensures that each microservice integrates well with the others while not interfering with the operation of any other microservice. 
  • Choose the right error handling strategy and ensure fault tolerance, apply the Circuit Breaker pattern.
  • Optimize infrastructure support time with an “Infrastructure-as-Code” approach.

Microservices are anti-ESB

You’ve probably heard of or worked with an enterprise service bus (ESB) on some level, and it’s important to understand that microservices go in a totally different direction, although they have a similar ancestor: service-oriented architecture (SOA). ESBs can be quite heavy on the backend as they rely on a centralized software system that integrates backend processes like data models, routing, requests, data models, and deep connectivity so all of that can be used in various applications. ESBs can be large, cumbersome architectures that require a lot of time and energy to maintain and repair. Microservices’ decentralized nature makes them faster and more agile, while still making it possible for developers to reuse pieces of code and fix problems quickly without impacting the whole system.

How APIs Connect Microservices

APIs are the connective tissue that brings those containers of microservices together, and are sometimes called “containers plus APIs”. Microservices need to be connected with other microservices, so the APIs provide the transmission of data between services.

Key Business Benefits of Using Microservices

With all of that in mind, microservices have some distinct advantages over older monolithic applications that can provide actionable business benefits: 

  • Improved agility that comes with well-defined microservices working together through well-structured API implementation. 
  • Using a DevOps approach with microservices enables for faster management of repairs, updates, and changes.
  • Independence—Microservices allow companies to detach from restrictive, cumbersome monolithic applications to a more modular, independent set of services that can be scaled as needed. 
  • Quicker and easier problem solving is a hallmark of microservices  
  • Better security opportunities spring from having a set of agile microservices that work together and that can be updated or fixed at a moment’s notice to prevent security risks to other areas.  
  • Fluid user experience comes from intelligent microservices design.
  • Better reliability and elasticity to fit changing business demands and opportunities.
  • Rapid innovation is moments away when DevOps teams are able to focus on their microservice without the distraction of other pieces of connected code that might create problems. 
  • New feature development is fast and furious with microservices. Think of a functionality need? Create a microservice to fill it very quickly, from development to QA and implementation. 
  • Growth in the ability to even use A/B testing to choose the best microservices options for your needs.

Company Culture Considerations and Microservices

Consider companies that have successfully disrupted their markets with microservices. Amazon and Netflix are only two examples. Etsy and even Walmart have successfully taken on real business challenges with microservices, but in each and every case, it wasn’t just a top-down decision to switch to microservices that did the trick. It took coherent, intentional decisions that involved the entire company culture, from inside out, to change the way they thought and communicated together. And it wasn’t just one decision, it was a continuum of decisions that led to evolution and change over time. You can’t teach an elephant how to dance without a clear idea of what you want that dance to look like in the end, just like you can’t change company culture at the top without effective and open communication and intentional effort between all of the stakeholders. And in the end, communication is the most important consideration for successfully implementing microservices. 

If that idea seems daunting, take a deep breath. It’s a process. The first, most important step is evaluating your “elephants” in the company and identifying how each stakeholder can effectively start communicating and working better together. This is one of the primary benefits of the DevOps model: Development + Operations = a much better outcome than each of them working in a vacuum. Nothing happens in a vacuum, after all. So, first consider the different stakeholders and perspectives and how they connect or communicate (or don’t, as the case may be): 

  • Current team structures and communication patterns 
  • Development, testing, build, and release processes  
  • Technical debt and existing commodity applications 
  • Differing goals or strategic visions between departments

Cultural Change is Essential for Implementing Microservices

This is, in part, because microservices is a turning inside-out of traditional application design architecture, which naturally grows out of its native soil of the company culture. In order to really grasp the agility and opportunities available with microservices, it takes a mindset change for everyone in the company. In fact, changing the technology isn’t the hard part, it’s the easy part. Cultural change is really the sticking point. A study from Gartner Inc. showed that 90% of companies that tried to implement a DevOps system without really digging deep into the cultural foundations of their companies failed to progress in their strategic goals. 

And the number one consideration in changing company culture is communication, a fact borne out in Conway’s Law: any system designed by an organization will turn out to be a striking copy of the company’s communication structure. If the communication structure is stilted and poor, the system will reflect that. If you do the work of changing your communication structure so that DevOps really works and all of your teams operate in sync because of that communication, then the resulting system will also reflect that improved communication.

The Partnership of DevOps in Microservices

Breaking down communication barriers can be a huge challenge, but there are strategies you can implement now to improve communication between stakeholders and eliminate the largely psychological separations that hamper progress. Here are two possible ideas for making that happen: 

  1. Have developers go out on a production rollout with the operations team. As the developers watch a real-time scenario unfold, they can get a better appreciation for client needs and what the operations team goes through. 
  2. Involve the operations team in the process of change orders and service tickets so they can see what developers go through whenever a new feature is requested or a problem is discovered and dealt with. 

When different teams converge and appreciate each other’s problems, processes and needs better, communication barriers start to fall and new solutions spring into action. It’s then that DevOps can activate their powers for highly agile and scalable microservices. 

Once communication barriers are broken down, the company can make real progress on teaching its elephant to dance by honing in on those strategic goals mentioned before. Understanding the culture, communication structure and workflows can open the pathway for disconnecting from monolithic applications to more fleet-footed microservices.

Where is Your Starting Point for Microservices?

If you’ve been contemplating how to jump into microservices and taking advantage of the agility and opportunities they make available, but aren’t sure how to start, hopefully some of what you’ve read here can get the wheels turning in the right direction. What microservices do you need? What microservices would boost your competitive advantages? Are you excited or worried about the communications changes you need to make within your organization? Let’s talk about where you are and what your strategic goals are and Spark Equation’s experienced microservices engineers can help you break down barriers and step up to new opportunities.

Leave a Comment