Day Two Cloud 082: You Don’t Need a Service Mesh

This week’s Day Two Cloud episode features Matt Klein, Lyft plumber and writer of Envoy. We discuss not only the need for service meshes, but more broadly the need for any new technology within your organization. Based on previous panels I have seen Matt participate on, I knew this was going to be an interesting episode. But I had no idea how just how excellent it would be! Seriously, give it a listen.

During the episode, Matt made the argument that companies should not adopt new technology for its own sake, rather they should be laser focused on what the business needs are and ensure that current technology is meeting those needs. Assuming it is, then they should not try and introduce new technology, as that will introduce new bugs and potential instability. On the surface, I broadly agree with what Matt said, but I tried to articulate a counterpoint. I did so badly in the moment, so I thought maybe I could try and flesh out my thoughts here instead.

There were three points made by Matt that I think can be summarized thusly:

  1. Use the simplest and oldest technology that meets your business goals
  2. Benefits from new tech must be greater than the pain of adoption
  3. Customer and business needs should drive technology decisions

Like I said, I broadly agree with these points, and in fact I have made many of the same arguments. At the same time, I think there is a need to be more visionary and strategic with technology, rather than being strictly pragmatic. There an apocryphal quote from Henry Ford, “If I had asked people what they wanted, they would have said faster horses.” which encapsulates the idea that customers don’t always know what they want, and it’s up to the innovator or inventor to give them a new alternative. While I think that is condescending to customers – it’s really on the interviewer to ask the right questions – the point is still valid.

Companies need to experiment with new ideas and technologies to stay ahead of their competitors and meet their customers not where they are, but where they will be. The level of investment in R&D should be proportionate to the level of competition. The public cloud has a high level of competition between a few companies, and we are seeing a concomitant level of investment in R&D. Amazon in particular is famous for having small teams working on new ideas or projects constantly. They are customer obsessed, trying to listen to what customers are asking for, but they are also making guesses and placing bets on new ideas as well.

The innovation at your organization is largely driven by what your company does. What is core to your business. To the extent that technology can accelerate your core objectives, it should be experimented with. Does this mean implementing Kubernetes for your existing mainframe application? Maybe. Like Matt said, the benefit needs to outweigh the pain. Perhaps your mainframe application is written in a language like COBOL, and it’s difficult to find folks to maintain it. Or the service contract for your big iron is about to expire and you need to buy new hardware. If this application is core to your business and helps you drive value to customers, then it makes sense to experiment with better ways of delivering it. Ask two critical questions:

  1. Can I lower my existing costs?
  2. Can I increase my revenue?

Lowering costs could come from a reduced administrative burden, higher efficiency, or a less expensive platform. Moving from specialized to commodity hardware (mainframe to x86) could reduce costs. Breaking apart a monolith could make service integration more efficient. Adopting a platform that is widely understood could reduce administrative burden over the long term – short-term there will be pain in the migration.

Increasing revenue comes from being able to process more transactions, improving the customer experience with new features, attracting a new market segment, or removing bottlenecks from the existing system. Adopting a popular platform also means being able to attract solid developer talent and being able to select from a wider pool of options.

Ultimately, I think my central point is that while you need to be pragmatic about your technology decisions, you are not an omnipotent being capable of seeing all potential futures. Choosing not to try something new carries a cost, as any economist would readily tell you. Organizations need to place small bets on technology and see what looks like it may bear fruit. The more competitive the landscape, the higher the reward and so taking more risks make sense. But I would go even further and say traditional businesses could benefit greatly as well. You’re looking for a marginal advantage. Experiments should be constant, just as businesses need to continually evolve.

Technology should not be adopted for technology’s sake, but it should be adopted as part of strategic experimentation. There is a balance to be struck between what is tried and true, and what will accelerate your company forward. You have to be willing to try new things, ignore sunk costs, and make strategic bets.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.