Enterprise CTOs have microservices on the mind. After relying for years on monolithic stacks, these IT leaders are trading in their old architectures for independently deployable systems and granular, lightweight services.\nSpeed and agility are what these CTOs are after, and microservices can deliver\u2014phenomenally, in fact. Microservices can empower companies to leave behind large, slow-moving teams and complex deployments, and to shift to agile, independent teams delivering on their own cadences. The opportunity is huge.\nBut while adopting microservices is easy in theory, practical reality is often less straightforward. Microservices resources and tools have grown abundant, and CTOs can look to success stories ranging from Netflix's architecture to the open-source Kubernetes project to Brazilian retailer Magazine Luiza's digital reinvention. This variety makes it easy to think, "I can do that." \u00a0\nThis is often where the trouble starts.\nWhat makes a microservices architecture so powerful is also what can make it challenging for large enterprises to adopt: it\u2019s not just another technology but rather an entirely new model that can impact virtually all aspects of business operations.\nI\u2019ve seen many companies navigate this transition, and, when it breaks down, it is often for the same reasons. The difficult and surprising parts don\u2019t always involve technology\u2014they often involve cultural and organizational change.\nTypically, if a large enterprise is going to implement microservices the right way, it needs to first transform the heart of its organizational culture. This challenging prerequisite can be traced to the fact that microservices are largely designed for (and by) small teams. There\u2019s a certain organizational inertia within larger enterprises that can be at odds with this granular approach.\nMicroservices: Solving 3 common challenges\n1. Speed vs. uniformity The first stumbling block large enterprises frequently run into when adopting microservices is balancing independence versus control. There is a tendency to say, \u201cDo what is right for you,\u201d and to then follow it up by asking, \u201cHow many vendors and skills should we manage?\u201d This can happen because large organizations tend to be prescriptive by default. While this is not necessarily a bad thing, it relegates true microservices to the realm of theoretical discussion.\nUltimately, there is no silver bullet. But when in doubt, it is often beneficial to favor speed over uniformity\u2014within bounds. (Do you really need three NoSQL databases? Not likely.) If your microservices are wrapped with clean APIs (see the third point, below), even better\u2014uniformity can always come later. After all, with clean APIs, implementations can change.\n2. The dreaded DevOps requirementAnother organizational challenge large enterprises often have to overcome is resistance to the additional skills and duties microservices impose on teams\u2014namely, the dreaded DevOps requirement.\nIf Team A builds a microservice, then it is truly their job to keep it up and running. Unfortunately, DevOps is not an acquired skill. It is not even a learnt skill, so to speak. Unlike programming languages, for instance, DevOps is an \u201cexperience\u201d skill\u2014one that only comes with the passage of time.\nTwo practical design principles can help you prevail: (a) invest in tools that simplify operations, and (b) for some really difficult things (such as managing a NoSQL database like Cassandra), have a separate team that can focus on those skills specifically.\n3. Chaotic contractsA third common issue relates to implementation. Devising and holding a contract with downstream teams is very different than walking over to the other team and hashing out the special features they need.\nIn the first scenario, you have a well-chosen contract (manifested in a well-documented API) that does not strive toward special interests of the \u201cloudest\u201d downstream team. The contract is therefore 1:N, and with N teams, there are O(N) contracts. In the second, you end up getting extensions that are bespoke and brittle. The contract is 1:1, and therefore, with N teams, we get O(N^2) contracts. For an organization with 1,000 services, that is a difference between 1,000 and 1,000,000 interfaces! \u00a0\nWhile the theory is perfectly clear (\u201cfewer is better\u201d), organizational dynamics can prevent its application. Enterprises facing this problem should explore an \u201copen to all\u201d approach to APIs.\nAll APIs and their documentation should be published, and all interactions between microservices should go through a registration process. As long as there are no side contracts, having too many APIs shouldn\u2019t be a problem\u2014periodic pruning based on observation of use can prevent any issues that crop up from getting out of hand. Openness with periodic reviews should be all you need.\nMicroservices: More than a tech implementation\nOrganizational challenges aside, microservices are likely here to stay. This architecture reflects the way software should be written. But to do it right, leadership should first understand that adopting microservices involves more than a mere technology implementation. In the end, it is an organizational change that gets down to the very fundamentals of independence and empowerment.