Skip to content

SO Apps 9: Creating Success with Microservices — Info Sources

August 2, 2017

Developing microservices might be more involved than you initially think. While a single microservice itself may be relatively small and simple, systems composed of multiple microservices are much more complex than one may expect since microservices dramatically affect numerous key areas in the entire software development and operations lifecycles.  This article describes the key areas affected through learning from people’s experiences with microservices, both successes and failures.  Herein I present a list of info sources I have found to be helpful during my own journey of learning to design and implement microservice based systems that started in 2012.  Also included is a synopsis of the “Key Areas for Success with Microservices” gleaned from those info sources.

About Microservices

Microservice systems are also distributed systems since each microservice, or group of closely collaborating microservices, is hosted within its own process.  And each such process is most likely to be hosted on a separate computer or virtual machine, thus acting to distribute portions of a single client’s workload across multiple computers.  These characteristics require the microservices to communicate with each other via a network, rather than communicating via much simpler direct method/function calls as is done in monolithic non-distributed systems.  Note that software running on distributed systems (e.g. microservices) is notably more difficult to design, develop, debug, and operate than monolithic software for non-distributed systems due to this networking, plus the, at times complex, orchestration needed to manage the concurrency of multiple processes running independently of each other.  Thus, microservices and distributed systems represent a major sea change for the mental models, tools, techniques and processes of software engineering, development, and operations due to their different characteristics, challenges and higher level of difficulty when compared to the monolithic systems and “apps” of the past.

The rise of microservices in the last few years is driven by 3 main factors, below, the first two absolutely requiring the use of independent services:

  1. The great and rapid increase in the use of distributed systems, as noted in Monty Montgomery’s “Escaping Appland” article below. In the “Great Expectations” section he describes a “major industry inflection point” occurring now where most “apps” developed now are in fact parts of a larger distributed system.  He also describes the implications of that inflection point.  One key implication is that since this growth in distributed systems has happened extremely rapidly, our current software development workforce has relatively few people having experience designing and building distributed systems, as described in his “Still Stuck” section.  This leaves organizations with the need to grow their own expertise in microservices and distributed systems mental models, technologies, and techniques. Note that microservice software architectures were originally developed to support distributed systems.  For more on distributed systems see my blog “SO Apps 4, Coping with the Rapid Rise of Distributed Systems”, 9/27/2015.
  2. The rise of the need for highly scalable software systems and the cloud computing platforms that supply the capability of dynamic scalability. A cloud is a distributed system by definition.  And microservices allow effective horizontal scaling way, way better than monolithic services do.
  3. The rise of the need for Continuous Delivery of feature updates to software systems. In many businesses it is no longer good enough to release new software feature updates each quarter, half-year, or year.  Microservice architectures can greatly facilitate a more rapid schedule of software feature update releases.  With sufficient automation, plus the other things listed below, an accelerated release pace is quite achievable and sustainable.  Please see the “Architecting for Speed” article below by Jesper Nordstrom and Thomas Betzholtz for an excellent discussion of this area.  Note, however, that this does not absolutely require microservices.  A well engineered, highly modular monolithic service can also support more rapid feature releases when there is also an effective deployment and operations process.

Given the higher level of difficulty of developing and operating microservices, we can learn about the main factors that create success with microservices from those who have had hands on experience developing them and facilitating their adoption by organizations.  Many of the authors of the below info sources have such experience. The general gist of the following info sources is this:

It’s a new world! Developing microservice systems requires new and different mental models and skills in each of several key areas, listed below.  Some of these areas are easy to miss.  Some areas are unforgiving.  And some of the knowledge and practices that worked so well for you in the past can be anti-patterns in the microservice realm.

Beware. As you will see from many of the articles in the following “Info Sources” section, if you are unable to provide what it takes to be successful in all the key areas below, the probability of large failure increases.  Large failure in software development typically results in unplanned longer development schedules, unplanned higher development and sustaining costs, and more software quality problems (more bugs).  These usually significantly increase the Time-to-Market of the initial release and most subsequent releases as well.  Plus, large failure entails a heightened risk of having to abandon a development project gone wrong or do a major rewrite of it, as you will see from one of the below info sources.  Large failure scenarios can be avoided by explicitly focusing on what creates success in microservice development projects, and making sure your organization is doing all the success creating things.

Key Areas for Success with Microservices

To be successful with microservices you need to adopt new mental models in each of the following key areas, plus develop the skills and ability to effectively execute within the new mental models:

o   The ability to decompose a business solution into a system of right-sized microservices – not too big, and not too small – so as to have an effective microservice architecture (the software’s structure) that fulfills your organization’s needs. Think of it this way: “Effective software structure significantly reduces Time-to-Market and Total-Cost-of-Ownership, plus speeds innovation”.  Copyright © 2017 by Solid Value Software, LLC. All rights reserved.

o   The diverse technologies needed to support microservices. This includes the mental models and technologies of microservices themselves, plus those technologies concerned with the broad and rapidly growing set of public cloud services that can be usefully consumed by microservices, new database and data storage models, new hosting models.  Also the technologies of software development, quality and testing, operations, and project planning and management as they relate to the specifics of microservice based development. This shows the very broad scope of the main areas involved in developing and operating microservices. It’s a new world!  P.S.  Microsoft’s Service Fabric was developed precisely to provide very efficient support for developing and operating microservices.  See the list of articles below for more.

o   Developers and other staff experienced in utilizing the above technologies, plus thinking in the terms of the new mental models (as opposed to habitually thinking in the terms of previous mental models and technology concepts that can well be microservice anti-patterns). Given the current workforce’s relatively low level of knowledge of the mental models and techniques required to develop solid microservices and distributed systems, there is a large need here for organizations to grow their own expertise.  Suggestions to support this are listed subsequently.

o   DevOps Processes and DevOps Tools. It’s a new world!  For an excellent description of this new world, its benefits, and how to make it happen I recommend The DevOps Handbook by Kim, Humble, Debois, and Willis.

o   The willingness and ability to do a major reorganization of the development and operations processes of your organization in areas involving microservices so that the processes explicitly excel at supporting success with microservices. This includes processes involving requirements, architecture, project design/planning and project management, software development, quality control, hosting, deployment, upgrades/rollbacks, microservice health monitoring, and heavy integration testing (an absolute must for distributed systems of any kind).  Plus a number of these areas need to use significant amounts of automation.  It’s a new world!

o   Effective governance, i.e. exercising control over the microservices and their support systems: Who has decision making authority in key areas? Who is accountable for producing what key results?  What to do to rapidly resolve issues when things go wrong?  How does effective communication happen within the organization given the preceding?  How does effective planning of features, development, testing, and releases happen?  As some of the below info sources show, just “winging it” here produces severe problems.  It’s a new world here too!

o   Adequate levels of individual, team and organization discipline required to effectively make all the above happen.

o   Strong management support, including support of people learning all the above over time so they can effectively do what is required of them to create success in this “new world”, plus calm acceptance of occasional small and medium failures.

That is quite a learning curve.  If your organization is new to microservice development here are some proven ways to reduce risk and climb the learning curve more surely:

  1. Start by discovering the overall goals and objectives for your microservice system, plus its key high level business requirements. Get buy in from all stake holders and write them down in a wiki. Things are much easier when you are clear on what you are trying to accomplish.
  2. Use staged development to reduce the risk of large failure by climbing the learning curve stage by stage, rather attempting to do everything in a single “big bang” project. Each successive stage gives teams a chance to learn new areas and then refine their approach to the area in subsequent stages.  For example, after the mission, objectives and high level requirements are done, then do a very high level architecture to act as a “road map” and “vision” to guide the stages of development.  Immediately after the architecture is done  do two or three very quick “proof-of-concept” code implementations of important, but very narrowly scoped, portions of the architecture.  Then learn from these and make adjustments in the next stage where you develop a Minimum Viable Product (MVP) or Pilot Project.  Then learn from that as well and make adjustments.  After the MVP you will have climbed a significant part of the learning curve.  You will now be in a much stronger position to do the subsequent development stages at a much lower risk and much faster, ultimately resulting in a fully functional production microservice system.  Plus an MVP/Pilot Project will give the business valuable insights and feedback irrespective of microservice design, technology, implementation, and operation matters.
  3. Setup your budget to fund your developers, operations, and other personnel to attend classes (in person or online) and to have time to do hands-on work with the new mental models and technologies by doing short exploratory coding projects in areas critical to the microservices project. This is key to growing your own expertise.
  4. Use appropriately experienced outside specialists engaged on a shorter term basis to assist your staff in some of the above areas. Such specialists can teach new mental models, technologies, techniques, and processes, plus also develop requirements, software architecture, project plans, detailed designs, and code to get your staff started in areas new to them.  Plus such specialists can assist individuals and teams in becoming much more productive with these new areas once they’ve learned the basics.

Finally, in my experience, becoming conversant with new mental models seems to be an important tipping point in climbing up the learning curve in new areas.  Once a person has “groked” a new mental model, all subsequent learning and application of the model becomes much easier and proceeds faster.  This can be a used as a leverage point in the process of learning and change.

Microservice Info Sources

The below info sources supply details and examples of the key areas in the above list:

  1. The Death of Microservice Madness in 2018” by dwmkerr, 1/12/18 on Medium.  This is my favorite of all the below info souces since it is very well written, succinct, plus covers all the necessary areas.  Of particular importance Kerr gives good detail about the challenges of state and  the versioning of messaging and state store schemas in section “The  complexities of communication are often ignored” that are seldom present in such articles.  If you only read one.  This is the one to read!
  2. Microservices – Not a free lunch!” by Benjamin Wootton, 4/8/2014.  This is highly worthwhile, by someone with hands on experience with microservices, devops, plus assisting organizations in adopting new technologies. Be sure to read the section titled “Distributed System Complexity” to understand what we are up against, i.e. “Distributed systems are an order of magnitude more difficult to develop and test against…” compared to monolithic systems.
  3. This is a worthwhile real world microservice failure story – “so we had no idea who implemented what and where”, and it gets worse! “Seven Microservices Anti-Patterns”, by Vijay Alagarasan, 8/24/15, InfoQ.
  4. From the Field: Escaping Appland”, by Michael “Monty” Montgomery, March 2015 in the IASA online journal.  Monty has been commercially architecting and developing microservice based systems for years — way before they became popular.  He’s seen it all, states the challenges very well, and has lots of experience with how to rise to meet and exceed these challenges and create success with microservices.  This article includes killer diagrams that make his point that here is a better way that has a much higher probability of success with microservices.  I consider this a must read and refer to it often.  Monty is a Master Software Architect with IDesign.  You can learn how to design microservices at IDesign’s classes, some of which he teaches.
  5. Architecting for speed: How agile innovators accelerate growth through microservices”, by Jesper Nordstrom, Thomas Betzholtz, 8/30/2016. This is an excellent wide ranging overview of microservices, good reasons why to use them, what the costs and risks are, and how their use requires new forms of organization of development and operations teams.  And, it shows how the architecture (software structure) of a software system is directly connected to business agility, i.e. reducing time-to-market.  The authors specialize in facilitating organizations in effectively adopting strategically critical technologies.
  6. Here is another worthwhile real world microservice failure story. “Failing at Microservices”, by Richard Clayton, 7/15/2014.  Note common themes in both of the failure stories involve issues with architecture, people, leadership and organization as major causes of problems developing microservice system.  These are things that technology alone cannot cure.
  7. The Astonishingly Underappreciated Azure Service Fabric”, by Ben Spencer, 2/10/2017. Microsoft’s Service Fabric microservice-oriented compute platform innately provides effective solutions for many of the microservice software development, hosting, and operations issues outlined in the above articles.  Service Fabric provides amazing DevOps features that automate many of the hard spots in deployments, upgrades, rollbacks, multiple service versions, and resiliency/availability.  That is because Service Fabric was explicitly built to do just that for Microsoft’s internal use.  Microsoft has found their internal Service Fabric to be so useful in streamlining their own development and operation processes for their hyper-scale cloud services like Office 365, Azure SQL, etc. that they are now selling it for use by their customers.  Service Fabric can be hosted in Azure, or in a customer’s on-premises data center, or in a private cloud, or in the new Azure Stack private cloud appliance.  And it can be hosted on either Windows or Linux servers.

Thanks to the authors of all these articles.

To the readers of this blog – I hope you find this information as useful as I have.

George Stevens

Software Architect, Sr. Software Engineer at Solid Value Software, LLC.

Creative Commons License

dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: