Gartner Blog Network

Microservices : Building Services with the Guts on the Outside

by Gary Olliffe  |  January 30, 2015  |  18 Comments

If you’re an application architect it’s unlikely that you have missed the emergence of the latest buzzword in our armoury : Microservices.   And, if you missed it before you’ve found it now.

Whether or not you are familiar with microservices, I want to introduce you to what I think is an important clarification of microservice architecture:  the distinction between simpler “inner architecture” and more complex “outer architecture”.

First, some level-setting… Microservice architectures promise to deliver flexibility and scalability to the development and deployment of service-based applications. But how is that promise delivered?  In short, by adopting an architecture that allows individual services to be built and deployed independently and dynamically; an architecture that embraces DevOps practices.

Need to release an update to your customer profile service?  Well, it’s “micro”, so it’s simple to grok and its developers can focus on just that functionality.  And when it’s ready, you can just test and deploy that service – no need to bundle it up with the rest of your application, no waiting for a release window. Is the same service creating bottlenecks when demand spikes in the evenings?  Scale out by deploying a few more instances of just that (micro)service.

It all sounds great, right? These are the aspects of microservice architecture that much of the discussion and excitement has centered around for the 12 months or so. These are the topics that have driven so much enthusiasm.

Microservices are simpler, developers get more productive and systems can be scaled quickly and precisely, rather than in large monolithic globs. And I haven’t even mentioned the potential for polyglot coding and data persistence. In my recently published research “Assessing Microservice Architecture for Scalable Application Delivery” I call this the “inner architecture”, it is the implementation architecture of the microservices themselves.

But it’s not the full story. To come close to the apparent nirvana of the (oversimplified) scenario above you have some work to do: you have a tremendous responsibility to stick to your interface contracts, and you have to manage the development, deployment and operational complexity of a distributed system.

The complexity you removed from your services to simplify them has not gone away and it brings new challenges, and amplifies old ones. You will meet this “moved” complexity when you test and deploy your microservices, when your microservices need to communicate, when you need to understand the health of your environment, or when you need to diagnose an issue this distributed, and potentially polyglot.

That complexity has moved and, I would argue, increased. It now lives in what I call the ”outer architecture”. The Outer Architecture delivers the platform capabilities you need to help all those simple little microservices (and their DevOps teams) work together to make good on the promises of flexible and scalable development and deployment. It is coping with this complexity that makes SDLC discipline and automation an essential element of delivering microservice architecture.

The diagram below is a simplified version on one published in my research, which shows how the inner and outer architecture relate. Microservices A through D are different services (possibly with different inner architectures) and each has one or many instances deployed and executing.

Inner and Outer Architecture

Inner and Outer Architecture

As you can see, the visceral elements of your architecture, the guts, sit outside your service implementations and the architecture inside each microservice encapsulates its logic and data persistence. If you start evaluating or adopting microservices you need to think about these outer architecture capabilities along with all the the fun inner architecture that everyone is so excited about.

Right now, my view is that the best starting point for the outer architecture is an aPaaS (application platform as a service) platform or framework. But, vendors will not miss the opportunity to “microservices-wash” their tools and platforms to get your attention. Some will be more suited to microservices than others, so I implore you to understand the capabilities you need using our research or by doing your own, rather than waiting for a vendor to tell you what they think you need (and should pay for.)

While not a panacea, I can see the potential for microservices to change the way we build, maintain and operate applications.  When delivered with discipline they help applications become more evolvable, more portable, and more adaptive, particularly as organisations look to migrate application workloads to private or public cloud platforms.  I encourage you to learn more about microservices from Gartner and the many other resources on the topic.

Just remember that delivering a successful microservice architecture takes guts.

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: application-architecture  soa  technology-and-emerging-trends  

Gary Olliffe
Research Director
1 year at Gartner
21 years IT Industry

Gary Olliffe is a Research Director in the Application Platform Strategies (APS) team in Gartner for Technical Professionals (GTP). He covers a range of technical topics, including application architecture, service-oriented architecture, application modernization and business process management. Read Full Bio

Thoughts on Microservices : Building Services with the Guts on the Outside

  1. […] Microservices : Building Services with the Guts on the Outside “If you’re an application architect it’s unlikely that you have missed the emergence of the latest buzzword in our armoury : Microservices.   And, if you missed it before you’ve found it now. Whether or not you are familiar with microservices, I want to introduce you to what I think is an important clarification of microservice architecture:  the distinction between simpler “inner architecture” and more complex “outer architecture”. … While not a panacea, I can see the potential for microservices to change the way we build, maintain and operate applications.  When delivered with discipline they help applications become more evolvable, more portable, and more adaptive, particularly as organisations look to migrate application workloads to private or public cloud platforms.” Via Gary Ollife, Gartner […]

  2. Chris Gaun says:

    Gary, I think it is good start but I am curious if Gartner clients want to know where microsorvices organization and architecture is a best practice and where it is not. I’ve seen lots of vendors marketing hard on this topic and throwing out a lot of confusing information that simply rebrands tech they’ve already had. Their dodge neither provides technology that builds features distinctly for microservices or helps organizations determine where to use microservices.

    Microservices were made popular by Martin Fowler when he described the concept in this and other blogs

    The blog focuses more on organizational changes that need to be made than actual app architecture. Because there are two arguments being made, I will call the enterprise structural changes that Fowler suggest “microservice’s enterprise”. I will call the application suggestions “microservices application architecture.” Because most enterprise customers would put microservices enterprise largely in the Forget_That folder, most software vendors are pushing exclusively for microservices application architecture.

    • Microservices application architecture is a hip rebranding of SOA. Fowler admits this fact and calls it “true SOA.” He and others feel SOA was coopted by ESB vendors. He doesn’t weigh in on whether another rebranding will be needed every five years as microservices is now being coopted by many private PaaS vendors. Microservices emphasizes dumb pipes (no ESB) and fully self-contained apps (database or new data store tech local to the app). (It is interesting that WSO2 – a ESB vendor – is now trying to scrape together a private PaaS to save their legacy sales)
    • Microservices application architecture doesn’t apply to ANY application that is transactional. The data within microservices is eventually consistent.
    • Microservices application architecture applies to very few existing applications – I’d guess that it is small single percentage. Fowler uses Amazon and Netflix websites over and over as the archetypes of microservices. Most apps, existing and new, don’t need to be Netflix. Some vendor frameworks were built to exclusively deal with this architecture, and have in turn not focused on other apps: They are pushing the concept hard in the market but it doesn’t change fact that many future custom internal apps will not follow this architecture and that organizations need should be able to handle both.
    • Microservices application architecture fly in the face of current database cost containment best practices – see Marcus Collin’s Gartner research on database virtualization. Best practices is to have databases on dedicated physical servers because commercial solutions charge on a consumption basis, usually by CPU core licensing. Even if the database is open source there needs to be a throat-to-choke so it is always a commercial distribution. Having a database packaged locally with each app, spread across many nodes, is expensive. You might wonder can database licensing change to accommodate this type of architecture. For example, can they charge for data processed like AWS does for some its products. They could do that but data is growing so fast that I doubt it would be a cheaper alternative.
    • For most organizations, Fowler suggest a radical departure from existing org charts. A microservices enterprise is organized by full stack teams. There would be a DBA, infrastructure people, app developers, et al on the same team. The app is then owned by that team for its lifetime. Most organizations are not going to completely restructure to build apps. A railroad is not going to be disrupted because they failed to change org chart and build a phone app no matter what some vendors says.
    • There are real organization impediments to a microservices based approach that crosses development team lines. When you buy into a microservice’s enterprise approach at a larger scale, you’re now taking both development and runtime dependencies on organizations you don’t control.

    How does it look when a dev group from Fixed Income says it’s going to be 6 months late because it’s dependent on a microservice being built by a group from Card Services? The business team isn’t going to stand for it – despite it potentially being a better technical service.

    This says nothing about the remaining technical challenges of discovery, mapping, etc.

    • Gary Olliffe says:

      Hi Chris – indeed our clients do want to know when MSA applies and when it is not appropriate and I cover that in more detail in my research doc (Gartner clients only).
      “Microservices-washing” is common at the moment, many vendors of SOA tech and aPaaS are putting a microservices spin on their pitch to get attention – it’s just marketing, so architects interested in the potential of MSA need to cut through it as I “implored” in the post.

      You are right that microservices applications are not “transactional” (at least not across microservice boundaries) and favour eventual consistency patterns, but just because the current implementation of an application is transactional it does not preclude the use of microservices (or any other BASE persistence architecture) if there are data contexts that don’t NEED to be transactional – some do, some don’t… it was just the way we built virtually all applications before eventual consistency came along.
      How you persist the data from your microservices (and share it between them) is a critical “inner architecture” decision, and my research doc gives four (by no means exhaustive) example patterns.

      Retrofitting microservices into traditional dev processes and org structures will undermine the likely benefits and should be avoided… maybe I should add a third layer to the diagram … the “organisational architecture”… when the org and it’s processes are not ready to adapt to MSA practices and structures I recommend that architects understand the (SOA) design principles and patterns that make microservices feasible and apply them to “macroservice” design and delivery.

      And if a microservice is going to take more than 6 months to build (and make another team “6 months late”) then someone messed up the scoping of the service and it’s highly likely to be macro and not micro! The teams working on individual microservices that are part of the same application need to be coordinated, even if their delivery lifecycles are independent. If the teams you describe are working in different application domains it has little to do with microservices and is a problem you’ll see in any “shared service” environment.

      As Ben Wooton wrote there is “no free lunch” associated with microservices.

  3. Jim Bugwadia says:

    Gary, great write-up! At Nirmata, we have been referring to what you call inner architecture as the “dev” of Microservices and the outer architecture as the “ops” of Microservices.

    Both need to happen for DevOps!

    Microservices combines patterns, and best-practices across software design (modular design), architecture (service-oriented), and organization (DevOps). It solves addresses several challenges with software development, but creates new challenges for operations. And this requires new tooling!

    I recently wrote about 5 essential architectural constraints for Microservices at:

    • Gary Olliffe says:

      Hi Jim – I resisted the temptation to call the two views “Dev” and “Ops” because there is what I consider dev environment architecture in the “outer architecture” (e.g. your CI tooling for example). I’ll check out your blog.

  4. Great post Gary.

    I’ve experienced these types of architectures up close. Especially one springs to mind that was created on the basis of these principles about 20 years ago. Today that architecture is still one of the best I’ve ever seen and the scalability is almost infinite. However that architecture has failed or surpassed its lifecycle depending on what view one have on things. The problems was among other that during the 20 year lifecycle the people that created the architecture and implemented it left for other jobs or retired. New ways of writing code and designing architecture came to fruition. New hires could not be bothered with or understand the old code so they started building on the outskirts of the core. In the end we had no choice but to create a new implementation based on partially new architecture designs.

  5. […] in large monolithic globs,” as Gary Oliffe, another Gartner analyst, explained in a recent post. The ability to quickly scale up these smaller chunks of applications into a larger configuration […]

  6. […] their tools and platforms to get your attention,” Gartner’s Olliffe says. Clearly, microservices aren’t out of the SOA woods […]

  7. […] provide real decoupling. We’ll talk about distribution of apps, as well as of services via microservice architecture. And yes, we’ll even talk about democratization, including the ways Docker […]

  8. […] of it; scoping services, refactoring, defining domains.  My recent microservices research and blog post give more detail on microservice […]

  9. […] of what an end-user would be more likely to consider the actual application. A microservice is part of the internals of what is the perceived application. It is important to remember that the microservice […]

  10. Great article. We have a similar take here at Forest Technologies. At Forest we believe there is an additional outer layer of complexity that is prevalent in most MSAs, the container. We have had “VM Sprawl” and there is a very likely bet that “Container Sprawl” will be the next challenge from Manageability of the microservices

  11. AS says:

    Thank you for inspiration – “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)”


  12. […] betriebliche Komplexität eintauschen. Gary Oliffe beispielsweise hat Microservices als “Services with the Guts on the Outside” beschrieben. Wahr ist, dass Microservices den Betrieb […]

  13. […] microservices outer architecture the gateway pattern is something quite popular, which is also elaborately explained at nginx […]

  14. […] As there will be a large number of smaller services it is important to get this right first. Read this blog by Gartner on how outer architecture plays an important role in a microservices-driven […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.