Start your project with Spark
Find a solution that's right for your business, on your terms.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
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” eliminates 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.
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 code lines 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 independently, 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, one microservice's potential failure 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.
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:
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.
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.
Microservices run best from what we call “containers”, 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.
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:
You’ve probably heard of or worked with an enterprise service bus (ESB) on some level, and it’s essential to understand that microservices go in a totally different direction. However, 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 back-end processes like data models, routing, requests, data models, and deep connectivity to 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.
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.
With all of that in mind, microservices have some distinct advantages over older monolithic applications that can provide actionable business benefits:
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 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 the 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 critical 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. First, consider the different stakeholders and perspectives and how they connect or communicate (or don’t, as the case may be):
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 technology isn’t the hard part, it’s the easy part. Cultural change is 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 their companies' cultural foundations 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.
Breaking down communication barriers can be a considerable 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:
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 in teaching its elephant to dance by honing in on those strategic goals. Understanding the culture, communication structure, and workflows can open the pathway for disconnecting from monolithic applications to more fleet-footed 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? 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.
.png)