An Incremental Path to Microservices – RHD Blog

Some interesting reading how modern cloud services development should be organized.


  1. Tomi Engdahl says:

    The Right Way to Plan a Migration (Forget Cloud-Washing)
    When you migrate without a plan, you risk cloud-washing.

    Some companies just don’t know what they need. They move to the cloud because everyone else is doing it. They take physical infrastructure and dump it into a virtual environment without asking why. Getting on the cloud will solve all our problems, right? Well, not exactly. When you migrate without a plan, you risk cloud-washing. Yes, you’re in the cloud but, no, you’re not set up to take advantage of what the cloud offers.

    What’s more, over half of cloud migrations go over budget and beyond the migration window, leading to unexpected problems for businesses, according to research from Gartner, Forrester, and others. The only way to avoid that fate is to decide which cloud benefits matter most, then plan a migration accordingly.

  2. Tomi Engdahl says:

    About When Not to Do Microservices

    statement about microservices and not doing them:

    “Microservices architecture is not appropriate all the time”.

    Doing microservices, or monoliths, or SOA, or Microliths or whatever fancy term gets bandied about at present is not the point. Businesses ideally will be looking for [new] ways to deliver customer value and technology can be a differentiator. The key problem we face as we journey down this path of “deliver value” is actually quite simple: uncertainty. We literally do not know what will deliver value. Customers are also poor at articulating it. ”

    Part of what they discovered is that 66% of the “good ideas” people have actually have zero impact (or even worse) on the metric it was intended to effect. The folks who are able to run cheap experiments, run lots of them, and learn what brings value to customers faster than their competitors are going to win.

    Microservices is about optimizing for speed.

    Pioneers go off and experiment with wild, divergent approaches running many experiments hoping to reduce uncertainty about what may bring value to a company in 3+ yrs. This “pioneering” effort is intended to turn up a few decent options that we can build upon and take to the next level. The “settlers” end up doing this. They figure out how to scale the product engineering, scale marketing, sales, etc. and build the pieces of the organization to make this product a successful differentiator. Ultimately over the years, as a result of competitive diffusion, etc. our new product is no longer uniquely differentiated but still delivers massive value. It will be around for a long time and there are things we can do to make it run more efficiently.

    So WTF? How does this tie in? Well…where do you think you fit in your organization?

    If you’re the Pioneers, stick with monoliths.
    As pioneers, you have to move quickly. You have zero ideas whether a “thing” will bring value. You want to run cheap experiments as quickly as possible and learn.

    Running lots of these small experiments don’t require building out a complete product and absolutely reduces the uncertainty in your idea. You may, at some point, come to a point where you build a Minimum Viable Product. But again, the point of the MVP is to test a hypothesis and elicit learning.

    Doing microservices at this point is infinitely overkill and will distract you from your objective: Figure out something that delivers value.

    If you’re the Settlers, you may need microservices

    Once you stumble upon something that delivers value, you will probably want to scale it. This involves creating a product team: product managers, testers, marketing, sales, etc. On the product side, you’ll want to be adding features and moving quickly, again, to run smaller tests about certain features.

    Again, our goal is to make changes quickly to test them.

    Microservices involves a lot of complexity. Matt Klein recently said, “don’t take on complexity when you don’t need to”. He’s absolutely correct.

    If you’re the Town Planners, you may need microservices

    We’re currently experiencing a lot of “microservices envy” in our industry. It’s easy to lose track of our jobs as technologists to help find and cultivate customer value using technology. Don’t over optimize and complicate things when you don’t need to. Solve the problems you have, not someone else’s.

  3. Tomi Engdahl says:

    What’s the hardest part about microservices? Your data

    We explore the challenge of dealing with data when creating and developing microservices.

    Using Spring Boot/Dropwizard/Docker doesn’t mean you’re doing microservices. Taking a hard look at your domain and your data will help you get to microservices.

    Of the reasons we attempt a microservices architecture, chief among them is allowing your teams to be able to work on different parts of the system at different speeds with minimal impact across teams. We want teams to be autonomous, capable of making decisions about how to best implement and operate their services, and free to make changes as quickly as the business may require. If we have our teams organized to do this, then the reflection in our systems architecture will begin to evolve into something that looks like microservices.

    To gain this autonomy, we need to shed our dependencies, but that’s a lot easier said than done.

  4. Tomi Engdahl says:

    Whisking Functions with Promises

    In this blog I will demonstrate how to build a simple nodejs function that can do reverse geocoding using Google Maps API, and how to deploy the functions on to Apache OpenWhisk.


Leave a Comment

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