In a recently posted article on DZone, “Microservices: Good for Developers’ Mental Health,” Sauce Labs engineer, Simone Pezzano, addresses the link between developer confidence and mental health in today’s new workplace. Pezzano tells the story of his team’s bumpy start on their journey from monolith to microservices. Initially, Pezzano viewed microservices as a scary concept with rapid release cycles and shorter testing times. But it would not take long for Pezzano and his engineering team to realize the beauty of microservices: they can make developers and quality engineers’ lives much easier.
"High confidence fuels good mental health among developers, which can have dramatic benefits for any business that depends on mobile apps, APIs or API programs, and web platforms."
The DZone article goes on to describe what Pezzano decided to set as top priorities on his team’s microservices journey in the names of speed and sanity. Here are a few key talking points from the article about increasing developer confidence in microservices:
Separation of concerns: good for business continuity - a commitment to single-purpose microservices allows developers to focus on very specific functional areas, reducing the risk of propagating errors; increased release confidence drives ongoing developer confidence
Reimagining speed as a way to reduce risk - by deploying small increments in rapid iterations–with a proper separation of concerns–developers gain the confidence to release faster, knowing that the impact of a bug that slips past flaky tests will likely be limited to specific areas of an application, avoiding the dreaded domino effect
Reduction of tech debt - microservices can elevate the "work smarter, not harder" philosophy to another level for developers; by mocking microservices APIs with proper contract testing during the earliest stages of development, developers can avoid a lot of headaches as they eliminate tech debt in staging environments
Designing systems to scale vertically and horizontally - by segmenting applications in purpose-oriented microservices, it becomes clear which services require higher parallelism, which makes it easier to know where to apply more efficient controls; developer confidence increases as the scalability issue naturally evolves into a well-defined scaling strategy
Failing fast, failing atomically - purpose-oriented microservices with mocking and contract or functional API testing, make it possible to be graceful when killing and restarting microservices when recovery from failure just isn't worth the time and effort; fail-first or test-driven approaches can really excel in microservices
Ensuring testability: sufficient coverage and black box testing - with less context, single-purpose microservices make it easier to ensure testability; verify technical specifications only as needed, and black box test microservices without deep diving into the internals of the system; microservices allow the black box to be smaller, less prone to defect, which increases confidence when validating expected cases or in exploratory testing that simulates unexpected cases
Improve black box testing feedback and get non-flaky test results by using dynamic data-driven API functional test automation that checks whole consumer flows and side-effects. Release confidence is sure to follow.
Testability: service isolation - microservices can be extracted from their location and connected to a virtual infrastructure–a process known as service isolation; this process increases confidence by stabilizing the environment for accurate diagnosis
Replaceability - microservices are designed to naturally evolve and organically improve over time; by posing strict barriers between functionalities, microservices increase confidence in an engineers' ability to swap functionalities with “as a service” or other products as needed in the future
A Movie set approach to data flows - the preceding eight confidence builders mostly flex on an overarching principle of a proper separation of concerns–but in the real world, engineers don’t always have the time to design all microservices properly; a "movie set" approach to microservices solves this problem by mapping data flows for a proper separation of concerns and using "facade microservices (aka, fat services)" as placeholders
Not enough time for proper separation of concerns? Create ‘microservices facades’ (fat microservices) that serve as placeholders to maintain the right data flow design until the facades can be decommissioned later and swapped with proper microservices.
Continuous Confidence
Ultimately, the journey to microservices involves embracing innovative API test automation tools that are designed to increase developer confidence. From mocking to contract testing and end-to-end functional testing, it must be top-of-mind for any microservices team to ensure that their API test automation suite provides sufficient coverage and visibility. A certain way to build developer confidence is to provide trusted feedback loops and global visibility for both short-term and long-term cases. In the short run, visibility should optimize testability, including black box testing at any scale, tackling any level of test case complexity. In the long run, true testability with visibility spanning across all microservices and API infrastructure will be able to reveal trends to help development and product leaders make data-driven decisions that improve customer experience, security, and reliability.
Read the entire article, "Microservices: Good for Developers' Mental Health" in the Microservices DZone.
Getting started with API testing? Check out our comprehensive API testing guide to learn more.
Sign up for a free Sauce Labs account (or sign in to yours) to begin using Free API Testing and Monitoring.
