For organizations trying to address development and deployment speed, the introduction of microservices architecture may be a solution. However, it can come with challenges - particularly around the complexity of many moving pieces.
Anders Wallgren, CTO of Electric Cloud, will discuss this very topic at the upcoming DevOps Enterprise Summit. We caught up with him to find out what CIOs need to know about microservices and DevOps. Read on for Wallgren's three DevOps "rookie mistakes," and a special discount code at the bottom of this article.
The Enterprisers Project (TEP): Your talk at the DevOps Enterprise Summit is focused on microservices. Can you talk about some of the benefits of a microservices architecture? What do you wish most CIOs knew about microservices?
Wallgren: The major benefit of a microservices architecture is that you can actually start to beat the Mythical Man-Month (i.e. the long-standing theory that adding people to a project lowers, rather than increases, velocity). Individual teams can develop and deploy code independently of each other, and it becomes possible to scale the productivity of the organization as the organization itself scales. This was shown very convincingly in the 2015 State of DevOps Report recently released.
One thing CIOs need to understand is that you don’t just buy a can of “Microservices” and paint all your code with it and be done. How you get there depends on whether you are trying to alter an existing monolithic application or are designing from scratch. Author Martin Fowler says most successful microservices start with an existing app and re-architect it and that it’s much harder to design for microservices from scratch.
Lastly, microservices are not a boon to everyone. On-premise software, for example, might not be right for microservices, given the amount of coordination and infrastructure that is needed to deploy microservices applications. That doesn’t mean on-premise software couldn’t be architected around a set of services, but the deployment scenario (e.g. ship as a single-war or as an installer) precludes deploying as such.
TEP: You and Gene Kim have spoken in the past about how to encourage more old-school thinkers and traditional organizations to embrace DevOps. Do you think there is still more hesitation than adoption? What are the biggest barriers you hear CIOs/IT leaders citing about not wanting to move to a DevOps model?
Wallgren: I think there’s more adoption than hesitation at this point, though there is perhaps some sample bias there since I spend quite a bit of time with individuals and organizations who are actively working on it. The biggest barriers usually end up being cultural – reporting structures that work against the goal of a single culture, compartmented teams with siloed processes, etc.
Another barrier, quite frankly, is where to start and right thereafter, how to show positive progress in a relatively short amount of time. My answer here is to treat the DevOps transformation as an agile project and apply agile methodologies. Have epics, user stories, backlogs, etc. for all your transformation work. Each work interval should show some measurable progress against the eventual goal. This is key because so many organizations (well, perhaps leaders more than the organizations themselves) think that it’s just a matter of buying some software and sending everyone to Scrum School, and then you’re DevOps. And I say this as someone whose livelihood depends on selling software, so you know it’s true.
TEP: As the pace of technology change continues to increase, do you see DevOps and continuous delivery as make-or-break methodologies for all organizations?
Wallgren: Quite frankly, yes.
I would use the car industry as an analogy – there are very few successful car companies that hand-assemble their cars, and the ones that do (Rolls Royce, Maserati, etc.) cater to a, shall we say, niche audience. The mass marketing of the automobile would not have been possible without the assembly line. What DevOps/CD addresses first and foremost is the “assembly line” of how we create and then deliver software.
Whatever your approach, you have to solve the assembly line aspect of how you deliver your software. Companies that do perform better in the market and have happier employees, as shown in the State of DevOps report.
TEP: For IT organizations just getting started with DevOps, what would you say are the top "rookie mistakes" they should look out for?
Wallgren: The biggest mistake by far is to ignore the cultural/organizational changes that have to happen and treat it as a tooling or process problem only.
Second mistake is to try to boil the ocean – to try to fix everything at once. Divide and conquer!
Third mistake is to spend too much time optimizing locally. This is a side-effect of compartmentalization/siloing. Everyone worries about making their little piece of the process better without paying attention to the bigger picture and optimizing globally.
The DevOps Enterprise Summit takes place Oct. 19-21 in San Francisco, CA. Friends of The Enterprisers Project can use promo code “ENTERPRISER20” for a 20 percent discount on registration.
Anders Wallgren is chief technology officer at Electric Cloud. Anders brings with him over 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award-winning technologies such as Macromedia’s Director 7 and various Shockwave products. Anders holds a B.SC from MIT.
