Is it time for your ‘microservices checkup’?

Daniel Bryant
microservices

© Shutterstock /  funnyangel

If you are thinking of performing your own checkup of your current microservices implementation, you should definitely read this article by Daniel Bryant, JAX London speaker and software developer and CTO at SpectoLabs.

Would your organization benefit from a microservices implementation review?

Many of our clients are currently implementing applications using a ‘microservice’-based architecture. Increasingly we are hearing from organizations that are part way through a migration to microservices, and they want our help with validating and improving their current solution. These ‘microservices checkup’ projects have revealed some interesting patterns, and because we have experience of working in a wide-range of industries (and also have ‘fresh eyes’ when looking at a project), we are often able to work alongside teams to make significant improvements and create a strategic roadmap for future improvements.

We’ve summarized our findings below, with the goal of providing inspiration if you are thinking of performing your own checkup of your current microservices implementation.

Technical fundamentals

In 2014 Martin Fowler stated that the prerequisites for a successful microservices implementation included rapid provisioning, basic monitoring and rapid application deployment. The OpenCredo team have discussed this internally to great lengths, and not only do we broadly agree with this statement, we have seen this validated within several projects.

Rapid provisioning

Rapid provisioning is becoming somewhat less important in 2016, what with the realization of microservice platforms, microservice compatible Platform as a Service (PaaS) and Containers as a Service (CaaS) like KubernetesMesos and Docker Datacenter. These platforms typically provide a homogenized pool of (or some other abstraction over) computing resource to which microservices can be deployed. However, some organizations choose to deploy onto Infrastructure as a Service (IaaS), such as the offered by Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure, and here the absence of rapid provisioning is a frequent cause of contention between development and operations.

As part of a microservice checkup project we typically look for warning signs like unrepeatable builds, manual assembly of infrastructure, and configuration drift (the dreaded ‘snowflake server’). The team here at OpenCredo are supporters of container technology and associated orchestration platforms. We are also fans of HashiCorp tooling, and regularly work with (and contribute to) Packer and Terraform. As much as HashiCorp are aiming for world domination, we, of course, realize that other configuration management tooling does exist, and we work a lot with AnsiblePuppet and Chef.

Basic monitoring

The ability to monitor a microservices implementation is truly vital. As the number of services deployed within an application increases, so does the complexity of interactions, and in turn, the potential for emergent behaviour becomes a reality (which is the sign of a truly complex system). As part of a microservice checkup we look for issues like undetected infrastructure issues (e.g. running out of disk space), alert storming (where so many alerts are triggered that it is impossible to know what the cause of an issue is), and production outages.

We regularly work with clients to help integrate and configure SaaS monitoring solutions such as DatadogSysdig and Ruxit and have also worked with local monitoring solutions like Prometheus. We are also strong proponents of synthetic transactions and critical smoke tests and have used tooling such as JMeter and Serenity BDD for this purpose. Often when we show this to project managers and other business stakeholders they wonder how they managed without this visibility into the application!

Rapid application deployment

The topic of rapid application deployment, and the associated theme of continuous delivery, deserve their own blog posts. However, in the context of a microservices checkup, we often find this is the cause of most contention within an organization adopting microservices. Many of us are used to working with continuous integration and deployment tooling like JenkinsGo CD and Spinnaker, but we often see problems emerge within companies when the implementation of a successful build pipeline from one team is applied to another team within the organization. If builds can’t be reliably and repeatedly deployed across an organization, or there is frequent production outages, then we look further into building support for scalable rapid application deployment. Frequently the issues associated with this problem must be addressed at the technical and organizational level.

Another common pattern we see is that initial microservice implementations or proof-of-concepts don’t integrate with the ‘legacy’ (money making) systems, and so the pain of implementing continuous delivery within this context isn’t experienced. We often work with the SpectoLabs team to overcome this problem, as they have extensive experience in solutions for this issue, such as Service Virtualisation and API Simulation.

Don’t forget the organization (and the people!)

For those playing microservices Bingo, this is where you check-off “Conway’s Law”. However, as we’ve discussed in other articles and presentations, the reality of the situation is that Conway was telling the truth

Organizational design and transformation

Often the first sign of organizational design struggles appear as a team moves from the proof-of-concept to implementation phase. As discussed in the ‘Rapid application deployment’ section above, as soon as the implementation expands beyond one team, then the complexity of interactions increases. This can often be challenging on a technical level, but it is almost always challenging on an organizational level. We look for red flags like queues of work, long delays or ‘sign offs’ on work as it moves around an organization, and teams pulling in different directions (or using competing technologies).

We have helped several companies review their current approach to goal-setting and organizational structure, from the development teams to the product teams, and also further upwards into the management level. We often work with the C*O level within organizations, as unless alignment and buy-in is achieved at this level, any changes made within the rest of organization can easily unravel.

The importance of ‘DevOps’

Although the term ‘DevOps’ has become somewhat overused (and still isn’t truly defined), we believe that the concepts behind it, such as a (1) shared understanding and responsibility across development and operations, (2) automation, with principles and practices driving tooling, not the other way around, and (3) creating signals for rapid feedback, are vital for success within a microservices architecture. As the number of application components is typically higher within a microservice-based application (in comparison with more traditional architectures) we often see problems emerge rapidly where teams are misaligned on goals, solving the same problem in multiple different ways; cargo-culting of automation, or the incorrect use of off-the-shelf ‘DevOps tooling’; and an absence of situational awareness.

The technical aspects of DevOps have been covered already within this article, but as with the previous section focusing on organizational design, the organizational and people aspects of DevOps are equally (if not more) important. We have seen DevOps implementations create fear within organizations, and we have also seen suboptimal processes being automated (automated failure is still failure!). Based on our experiences we have developed programs to assist with the transformation to a more ‘DevOps’ way of working. We also believe that concepts and goals behind the ‘DevOps’ movement are vital in the wider business context and the current economic climate, where time-to-market and speed of innovation are clear competitive advantages.

Could you benefit with a second pair of eyes?

As the cliche goes, at OpenCredo no two engagements are the same, as we tailor our services to each client and project. We aim to make systemic changes and provide as much knowledge transfer as possible so that any implemented solutions are sustainable in the long term. Having said this, we have identified several broad categories within the context of microservices with which we repeatedly help clients.

  • Monolith to microservice assessment
    • Should you migrate to a microservices architecture now, or would you benefit from another solution? Frequently clients want assurance that microservices will solve scalability and performance problems when in reality there are underlying architectural, design and data modeling issues that must be addressed first
    • We can help you design a monolith to microservices migration strategy. For example, we can help you answer questions such as: should you extract existing functionality to new services, what functionality should you build first as a microservice (and how to model the data), and how do you integrate services with legacy applications?
    • Do you want guidance on how your organization can ensure readiness for a microservices implementation (from creating strategic alignment on goals, implementing the most appropriate organizational structure, to embracing the ‘DevOps’ philosophy)?
  • Business and organization review
    • Does your team understand the flow of value through the organization? OpenCredo have helped organizations to better understand their value stream map, and then helped them increase innovation (via experimentation) and reduce lead times
    • Is your organization becoming overwhelmed with ‘Shadow IT’? Are teams creating and deploying microservices to different platforms? OpenCredo can offer guidance on how to bring IT out of the shadows.
    • Are staff actively resisting change? We can help you understand how to improve learning and communication
  • Microservice platform/infrastructure recommendations and guidance
    • Are you looking to leverage a PaaS solution, but don’t know which to choose?
    • Do you want to introduce containers (Docker) into your infrastructure stack, but aren’t sure how to approach this, deploy a solution, and keep it running?
    • We can provide guidance on the benefits and drawbacks of platforms such as Apache MesosKubernetesAWS ECS and Docker Datacenter
    • OpenCredo are experts in programmatic infrastructure and the associated tooling, such as HashiCorp Terraform and Packer, Ansible, Puppet and Chef. We can ensure that you are using these to best effect across your development and operations teams
  • Continuous delivery of microservices
    • We can help you build a CI/CD pipeline that supports rapid delivery of tested and validated application components from development to production
    • We can assist you with validating the effectiveness of your current build pipeline. For example, do you have to deploy multiple services simultaneously to prevent integration issues (the dreaded ‘distributed monolith’), or do you have multiple manual testing validation gates?

This post was originally published on the OpenCredo blog

 

Daniel Bryant will be delivering one talk at JAX London which will focus on the high-level steps that are essential for creating an effective pipeline for creating and deploying containerized applications.

asap

Author
Daniel Bryant
Daniel Bryant is a Principal Consultant at OpenCredo and CTO at SpectoLabs. He specialises in enabling agility within organisations, creating and leading effective software development teams, and maximising the impact of software delivery. Daniel’s current work includes introducing better requirement gathering and planning techniques, focusing on the relevance of architecture within agile development, and facilitating continuous integration/delivery.

Comments
comments powered by Disqus