Batch processing and offline maintenance are terms once feared as much as memory and computer power were yesterday. The eruption of microservices and similar technological advances has changed our perception of possible.\n\n\nA trend has emerged, and it\u2019s the opposite of what convention would tell us. Companies are first building out technical capabilities using a "monolith first" strategy for developing codebases. Monolith-first applications are made up of modules forming software applications that are not independent of the core application. This strategy is later followed by transitioning these monolithic structures into more scalable microservice architectures.\n\n\nAt the surface, it appears that every industry \u2014 including financial services, energy, and yes\u00a0even real estate \u2014 has benefited from using the design principles of modularity. Informed technology leaders understand the benefits that microservices offer and are wrapping them around their business models.\n\nDesign by service using SOA\n\nModern programming languages such as Java, Python and C\/C++ enabled the development of server-side applications. These languages decomposed complexity by adding abstractions. The language abstractions depended on sharing resources (memory, database, files) to create a single executable artifact, also called monoliths.\n\n\nUber followed the lead of Amazon, Netflix and Twitter in the movement to divide monolith application structures into chunks to form service-oriented architectures (SOA). The Uber stack was composed of three stagnant pillars, or monoliths:\n\n\nUsers to products to background checks.\nTrips to cities to vehicles.\nPayments to documents to promos.\n\n\nNearly all of the functionality Uber provided riders and drivers was woven into this value stack. Stability and performance worked well: The ability to scale didn\u2019t work. After expanding to 66 countries and building ecosystems across 545 cities worldwide, Uber was losing software agility. Flexibility, which was once a strength, quickly became a liability.\n\n\nFlexibility and scale improve by decoupling messaging queues, UI layers, client adapters, databases and external integrated services from the core application.\n\n\nStill trying to get your head around the value of a microservice? This example might be helpful.\u00a0Microservices are designed around business capabilities: These independently deployable services have limited responsibilities and run as a suite of smaller services that together comprise a single application. Instead of running one single mega application, you run a suite or group of smaller applications.\n\nBenefits of microservices\n\nLike any architecture style, there are times when microservices offer value and situations when alternatives should be explored. Strong modularity boundaries, independent deployments and technology diversity are the core benefits of leveraging microservices architectures. Another benefit of microservices is the ability to deploy services by fully automated deployment machinery.\n\n\nThinking you might already be using microservices? Here are several questions to ask that will help you confirm whether microservices are used in your technology environment.\n\n\nIs functionality broken into business components, not technical service components?\nAre your communications stripped of business processing logic and only distributing messages between endpoints (smart endpoints and dumb pipes)?\nAre applications organized around business capabilities?\nIs there a central governance over the monolithic application, or is governance decentralized by service?\nDoes your organization design and build systems or leverage more evolutionary system designs?\nHave infrastructure components been automated, enabling independent deployment capabilities by business functionality?\n\n\nThe benefits of the microservices architecture styles are many, including dynamism (splitting load), modularity and reuse (breaking complex services into simple ones), distributed development (distinct development teams working in parallel), and integration of heterogeneous and legacy systems (standard communication protocols).\n\n\nAssessing your business needs and technical capabilities for the new year? Consider adopting advanced distributed architectures for improved scale.