Disclaimer: This is a lengthy post with perspectives for both developers and marketers. Click on one of the links below for a shorter read. Enjoy!
In his now-ubiquitous explanation of microservices architecture, devops thought leader Martin Fowler seeks to explain the latest development trend to the layman. But he doesn’t do it as you might expect—by describing how microservices came to be or what it can do for your business. He starts by explaining the status quo: that large, enterprise brands have become too slow to dance on the bleeding edge of technology because they rely entirely on a small number of large, server-side applications—what he calls monoliths—to manage website features and functions.
Luckily, there is an alternative: Microservices architecture breaks these applications down into smaller, more manageable chunks, linking them together through APIs. This architectural structure helps make businesses more nimble and more prepared for the complex future of online customer experience.
Forrester agrees. In a report published in August, 2015, analyst Mark Grannan said “In 2014, digital experience technology decision-makers cited integration with back-end systems as
the biggest technical hurdle they faced in delivering great digital customer experiences. In 2015, ease of back-end integration tops the priority list.” He went on to suggest that companies persisting with a monolithic services architecture would result in “data models and processes that are fragile and inflexible,” slowing down innovation and preventing the adoption of new features.
This all-too-recent history lesson is critical to understanding the rise of microservices. As tech bloggers breathlessly declare 2015 “The Year of Microservices,” you may be wondering what has the developer community so hot and bothered?
In this post, we’ll explain why developers love it, why marketers should love it, and how your business can use this trend to your advantage.
In Good Company
Microservices architecture excites developers and marketers alike. And for good reason. Show me a digital customer experience you salivate over, and I’ll show you a leader in microservices architecture. Netflix, Nordstrom, Conde Nast, eBay, Target, Amazon and PayPal all employ microservices to go harder, better, faster, stronger; adding millions of customers without breaking a sweat.
So, is microservices just the latest fad? It should be stated that putting in a microservices architecture is not something you can do overnight. It requires planning, strategy and consistent execution. While it has not yet stood the test of time, we think that all forward-thinking businesses should be moving toward a microservices future.
A Developer Revolution
While we have increasingly seen dollars migrate from tech to marketing, demands on IT have continued to rise. With these demands have come complexity, where IT teams need to keep everything organized and distribute workloads as best they can, developing better applications at greater scale to stay on the customer experience cutting edge.
Some pundits argue that Services Oriented Architectures of the early 2000s never really caught on. That certainly was not the case at Amazon. But in other instances, big companies resisted the organizational changes required to dedicate teams around each service and business function.
But according to InfoWorld Editor-In-Chief Eric Knorr, this time around, developers are leading the switch to microservices, and the higher-ups are not fighting them on it. With rising expectations from business stakeholders, developers have increasingly relied on dynamic and automated processes and smaller and smaller services to handle the larger workload. As one developer, quoted by Knorr, put it, “whenever we encounter something that clearly looks like it should be a separate piece, we turn it into a service.”
Why Developers Love It
If you ask any developer what they hate most, you are likely to get the same answer: redundant work. No one likes to waste time, but for developers, increasing efficiency and reducing tedium are paramount.
When services are shared, redundant work can be drastically reduced. Instead of a small number of monolithic applications maintained by different teams, each duplicating each other’s effort, you can compose your applications from existing services already built and deployed by others. Smaller, more agile services are easier to maintain, code and improve.
1. Faster & Lower Cost Enhancements
For IT shops and developers, effort is measured in hours, and time is money. The sheer size of a monolith application—with hundreds of thousands (or more) lines of code—makes it slower to load when adding and deploying changes. This slows development down to a crawl and drives developers crazy.
This is a major problem because, according to this IT Revolution State of DevOps report, developers are deploying more frequently. Continuous deployment is impossible when you have to redeploy the entire monolith with every change you make. It would take forever.
Microservices not only save time in development but also maintenance. Since services are shared between many applications, when that service is improved, every application using that service benefits.
Lastly, developers can identify and correct issues more quickly within modular applications. Tools like automated testing can even further improve efficiencies and quality.
2. The “Micro” Is Key
In the old Service-Oriented Architecture days, services could be any size, including lumbering, old enterprise apps retrofitted with APIs. At the time, enterprise architects elected to cover as much functionality as possible, designing for all cases. In practice, this reduced agility and defeated the purpose of a strong services tier.
Now, it is pretty well understood that each service should perform a single function.
But just because each service performs a single function, that doesn’t mean you should code it for a single use case. Forward-thinking developers are now adopting what Grannan calls a “modular code philosophy”–implementing developer practices like range testing, which ensures that each service has some inherent flexibility beyond its “micro” function.
In the past, developers would try to customize large, monolitic applications with single, point-to-point integrations. What happened was these integrations wouldn’t scale; they would need additional customization to be used anywhere else and they would inevitably result in the thing developers hate most: redundant work.
3. Play To Your Strengths
Developers also benefit from added flexibility. Because each service is independent, each one can be built in a separate programming language or environment, allowing individual developers to play to their strengths, and allowing project managers to assign tasks to the most qualified person. This allows development teams to be faster and more effective.
4. Make IT More Valuable
For most businesses, technical debt is a problem. It basically refers to the cost of the technology required to add a new customer. With old-school application and integration architectures, new features, functions and capabilities add to the overall system complexity. By ballooning this technical debt, IT departments are eroding the gains their business achieves from each customer acquisition.
Microservices are specifically designed to be scaled and replicated. They are built small, with limited scope and functionality, by design. Underperforming or buggy code can be isolated and re-worked without impact to the other services or functions. This saves money and reduces risk of service interruption.
This line of thinking evolves IT to be more customer-centric, giving them the pivotal role they deserve in creating, maintaining and satisfying new and existing customers.
Why Marketers Love It
While there may be a few exceptions, most marketers don’t focus enough on enterprise architecture. Which is a shame, because their jobs increasingly rely on it. With dollars flowing from IT to business stakeholders year after year, technology decisions are increasingly influenced by marketers, leaving them to solve increasingly complex problems.
As feature-rich web pages become the norm, data and content are pulled from more and more systems and must be readily available across all devices. Marketing and business stakeholders also expect innovative features and functions to differentiate their brands. This requires a detailed understand of how technology can enable scale, performance, time to market and, ultimately, customer experience. Most marketers fall back on one answer when faced with these complex issues: the cloud.
Cloud systems, whether they be SaaS, Paas, IaaS or other, help you scale and reduce dependencies on in-house IT resources. Many marketing organizations see it as an opportunity to increase agility and reduce risk. But what happens when a dozen or more systems you depend on are distributed across diverse networks and built around point-to-point integrations? The truth is, without back-end integration techniques like a microservices architecture, cloud “solutions” will actually exacerbate the problems that marketers wanted to solve.
With or without the cloud, microservices can provide significant business benefits.
1. Add New Features
If customers are clamoring for new functionality, marketers and business leaders/stakeholders want to get it live as fast as possible. After all, every second they wait could be losing them customers.
A monolithic, single-application architecture reduces the breadth of enhancements or modifications you can make without well-coordinated, well-planned releases.
But according to recent surveys, developers are deploying more often than ever before. This is due, in part, to the rise of microservices and the demand for more feature improvements more quickly.
When marketers can deploy new, revenue-generating features faster, they engage prospects to become customers and customers to become loyal advocates.
2. Add New Capabilities
Every marketer has a roadmap for adding business capabilities. With marketing and business stakeholders never sitting idle, the promise of the next cool tool, widget or software release is adding complexity. Oftentimes, that requires adding new applications.
According to a recent study by Econsultancy, 51 percent of organizations are now using 21 or more digital marketing solutions. Bidirectional data flow between these systems is becoming the norm. The old school integration models were not scalable and extensible enough for the modern business and marketing operation.
3. Improve Customer Satisfaction
Typically, a standard deployment is going to come with some errors. But according to the microservices masters at Netflix, their developers deploy one hundred times more often (from once a quarter or once every 6 months to releasing about 100 times per quarter).
But here is the kicker: they have 1/10th of the outages and at about half the cost of a monolithic architecture.
Netflix top engineers believe this is because these units of work are small, simple and relatively easy to roll back.
This further reduces time to market, but also protects against bugs getting to the live site and disrupting user experience.
1. Technology Selection
In order for a microservices system to function properly, all of the individual services must be able to communicate effectively and efficiently.
Working with architecture experts during technology selection can help you identify which technologies will integrate most easily. This often involves an examination of how robust and complete the API is, identifying gaps and setting up a plan to fill those gaps with development.
2. Limited Resources
Implementing microservices can be a challenge. Distributed systems are an order of magnitude more difficult to develop and test against. Upfront costs and planning requires added resources, but the long-term payoff is well worth it.
Testing is a big concern as well because you often can’t be sure how two systems will play together when services are being coded separately. Time and effort must be invested toward a smart, comprehensive testing strategy.
Often, the largest barrier to microservices is short-term cost. To implement and maintain a microservices architecture involves strong devops experience, working with engineers who can build and deploy while keeping operational concerns in mind. Most ordinary operations teams are not able to manage it on their own. Working with an outsourced engineering partner is often a good way around this.
How Can You Get Started?
1. Get Internal Buy-In
The first step to creating a microservices architecture is to sound the alarm. The truth is that, despite highly-lauded digital customer experiences relying on microservices to get the job done, most project stakeholders admit that digital experience projects almost never enjoy the budget to address enterprise integration architecture in a meaningful way. Organizational silos add to the challenge, with many business and marketing stakeholders left out of the architecture discussion. With dollars and clout flowing from IT to marketing at many big brands, successful marketers should examine microservices and abstraction layers with the help of their IT teams. As Grannan put it recently, “over time, the organization will treat this growing portfolio of services as a key asset, recognizing increased digital experience agility.”
2. Technology Audit & Strategy
Once you have proven the concept to your contemporaries, an audit of existing technologies, services and applications is a logical next step. This should conclude with determining project scope, goals and next steps. Few companies can stomach an “all-in” re-architecture effort, though some have tried. Projects should be scoped to include robust integration efforts as part of a long-term strategy.
3. Technology Selection
Technology selection is key to reduce roadblocks that can come from implementing APIs. If you have employed cloud computing, special focus should be placed on the integration architecture and how you can continue to scale at the pace of today’s best technologists.
Microservices are an evolution of a broader industry trend toward more modular, granular architectures. According to Mark Grannan, some software vendors are choosing open, extensible architectures, moving away from a tightly dependent suite of features. “Some packaged platforms are embracing a service-oriented architecture (SOA) or service-layer approach across their portfolio,” Grannan writes. “These modern architectures are often displacing legacy, monolithic solutions, and for good reason.”
4. QA & Project Management
Because a microservices architecture requires significant and well-thought-out testing, having a good QA and project management strategy is essential.
5. Get Some Help
Talking with consultants with experience in this area can be a good first step to get a sense of the time and total investment required.