Microservices based architectures are not new but are suddenly in the spotlight due to their powerful and sophisticated practices enabling streamlined application development and deployment. However, transitioning from a monolithic approach to a microservices-based architecture requires not only technical expertise, but organizational buy-in as well. In a recent ActiveState webinar, John Wetherill and Phil Whelan discussed a number of tips and tricks to help companies transition to and get the most out a microservices-based approach.
They covered:

• Start small, move fast You need to start small with small teams since most companies do not have the resources to make a wholesale change at once. It is much more effective to choose or identify a small project that you can focus on and just get that working.
• Leverage external microservices/APIs Get into the mindset of consuming APIs that you have no control or knowledge of regarding their implementation. Become familiar with using external microservices before starting with microservices yourself, with your existing apps.
• Align dev/test/stage/QA/production environments Make all of your environments absolutely identical; you will avoid a lot of problems. This applies to microservices and non-microservices environments.
• Steward APIs Build and maintain client libraries for access to the microservices API. If not, the construction of these libraries is left to third parties, resulting in fragmentation when implementers incorrectly interpret the spec or do not fully comprehend the logic of how it’s called.
• Leverage reliability requirements early Identify reliability requirements earlier in the dev process so that you design and build your applications to follow them. The consumers of these services will then have a better idea of what to expect for reliability, SLAs etc. Reliability must not be an afterthought.
• Eliminate IT barriers The point is to empower teams instead of working microservices into a system with existing barriers. We need a different approach in which IT is behind an API – users can invoke the API to provision resources as opposed to having to submit a service desk ticket to do so.
• Be prepared to retain backward compatibility forever It’s common to deploy new microservices side by side with old versions (which can be eventually removed). However, there are cases where devices out in the field cannot be patched or updated. In these situations, backwards compatibility must be retained.
• Complete doesn’t mean shipped Don’t just wash your hands of your code once it’s shipped the first time. The development team should retain interest in it for its lifetime.
• Fail fast, recover quickly There are always going to be failures: embrace and encourage them. If get into the process of breaking as many components as possible, even while in production, you will necessarily develop recovery processes ensuring the ensuing systems will become more resistant to failure.
• Identify synchronous vs. asynchronous services Identify how the calls need to be made early, so that you can develop for them and minimize impact on performance.
• Minimize synchronicity It’s difficult to optimize for efficiency and performance if there are a number of blocked services due to synchronicity. Build systems around this to deal with it in real-time.
• Consider Feature Flags Feature flags are toggles that enable or disable certain functionality of the service. These can be used to change the behavior of the service, in real-time, by setting or disabling the flags.
• Step away from the infrastructure Don’t tie yourself to the infrastructure. It shouldn’t matter to development teams what the underlying infrastructure is.
• Split and denormalize schema The old practice of sharing a monolithic database across multiple applications / services doesn’t work well in a microservices shop. Instead of a common schema that spans multiple microservices, consider sharing the data via a separate service, which is accessed via the service API. Another option is denormalizing the data and duplicating it across the services. As counterintuitive as this may seem, these practices allow for more flexibility and agility in application delivery.
• Research practices, tools, APIs, components, patterns Stay on top of what is happening in the field, it’s important to find the right tool or process for your needs.
• Quantify success If you want to convince the rest of the company that microservices are the way to go, you need to measure and quantify your success. Numbers are your friend.
• Monitor from day one Start monitoring from the first line of code, then you don’t have to deal with it at the end where there will be other pressures.
• Secure from day one How do you patch the system? What happens when vulnerabilities come up? Plan and architect for this from the start.
• Scale from day one What happens when you get your application functional and everything working and then realize that you’re going to have to respond to millions of requests a day? Be ready for it.
• Fail from day one There’s no point in trying to prevent it, failure will happen. Plan and learn from it.
• Automate from day one In order to build resilience and get teams moving fast, you need to automate the release process. Otherwise, you’re not going to achieve several releases a day or get code flowing freely through continuous integration pipelines.
• Weigh polyglot vs. monoglot You should be able to build each microservice using the language best suited for the requirements its solving, and best-suited for the team building the service. On the other hand, it can be beneficial to limit the language choice across the organization to simplify tooling and knowledge requirements.
• Design versioning protocols Design versions in such a way that if any consumers have not moved to the new version, they can continue to use the old version. Using an immutable service architecture means you can keep pushing new versions, leaving old versions running unchanged and unaffected.
• Empower developers Ensure that your developers have much power as they need to be able to build out the systems, understand the QA and deployment process, and be involved in all parts of the software delivery process.
• Be prepared to discard The more granular the microservice the easier it is to discard or change.
• Identify internal proponents early In your quest to move your organization to a microservices architecture you’ll need allies to help spread the word. Identify these soon, at as many levels of the organization as possible, and after you’ve been able to measure tangible positive improvements (see previous point) make sure you communicate these to the proponents. The more folks you have on board, the smoother the transition.
• Choose the right project When you’re just starting out with microservices, you are learning a new paradigm. Be thoughtful when picking a project and set yourself up for success. Low hanging fruit, especially in terms of new projects, are always a good option.
• Choose the right PaaS PaaS is a vastly evolving market with a lot of different solutions. Look at what you want to achieve, and at the tips and tricks we’ve mentioned, to see which solution has the core features you need.