An Incremental Path to Microservices – RHD Blog

https://developers.redhat.com/blog/2017/02/21/an-incremental-path-to-microservices/?sc_cid=7016000000127ECAAY

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

11 Comments

  1. Tomi Engdahl says:

    The Right Way to Plan a Migration (Forget Cloud-Washing)
    When you migrate without a plan, you risk cloud-washing.
    https://arstechnica.com/sponsored/the-right-way-to-plan-a-migration-forget-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.

    Reply
  2. Tomi Engdahl says:

    About When Not to Do Microservices
    https://developers.redhat.com/blog/2017/10/19/about-when-not-to-do-microservices/?sc_cid=7016000000127ECAAY

    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.

    Reply
  3. Tomi Engdahl says:

    What’s the hardest part about microservices? Your data
    https://opensource.com/article/17/5/hardest-part-about-microservices-your-data?sc_cid=7016000000127ECAAY

    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.

    Reply
  4. Tomi Engdahl says:

    Whisking Functions with Promises
    https://developers.redhat.com/blog/2018/02/26/whisking-functions-with-promises/?sc_cid=7016000000127ECAAY

    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.

    Reply
  5. Tomi Engdahl says:

    What are microservices?
    https://opensource.com/resources/what-are-microservices?sc_cid=7016000000127ECAAY

    The central idea behind microservices is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. Each component is continuously developed and separately maintained, and the application is then simply the sum of its constituent components. This is in contrast to a traditional, “monolithic” application which is all developed all in one piece.

    Reply
  6. Tomi Engdahl says:

    About When Not to Do Microservices
    https://developers.redhat.com/blog/2017/10/19/about-when-not-to-do-microservices/?sc_cid=7016000000127ECAAY

    “Microservices architecture is not appropriate all the time”.

    Let me expand a little bit.

    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. We have lots of ideas, good ideas sometimes, but we don’t actually know the what to deliver customer value until we experiment and try.

    66% of the “good ideas” people have actually have zero impact (or even worse)

    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.

    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. You may not even be writing any code!

    the most inefficient way to test a hypothesis is to build it out completely. In his story, he talks about reducing uncertainty by coming up with a hypothesis like “people who take pictures of wine probably might want to buy that wine” and coming up with cheap experiments to test that hypothesis.

    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. An MVP is not product engineering. You’re not building this for scale. In fact, you’re doing the opposite. You’re probably going to be running MANY MVP tests and throwing them away. A monolith is a perfect way to attack this. A monolith will actually allow you to go faster because changing things quickly can be done all in a single place.

    Reply
  7. Tomi Engdahl says:

    5 guiding principles you should know before you design a microservice
    https://opensource.com/article/18/4/guide-design-microservices?sc_cid=7016000000127ECAAY

    Top CTOs offer advice for a well-designed microservice based on five simple principles.

    Reply
  8. Tomi Engdahl says:

    How to solve the challenges of creating automated tests for microservices
    http://www.electronics-know-how.com/article/2614/2614

    As an architecture for building complex systems, microservices is gaining significant traction within the development community. Especially applications that share challenges related to dependencies and scaling can benefit greatly from it. Microservices adoption is on the rise, but so are the struggles associated with understanding how to test microservices.

    Toby Clemson from ThoughtWorks has done a great job of enumerating testing strategies that you might want to employ in a microservices architecture

    Reply
  9. Tomi Engdahl says:

    5 microservice testing strategies for startups
    https://opensource.com/article/18/6/five-microservice-testing-strategies-startups?sc_cid=7016000000127ECAAY

    Testing microservices isn’t easy, but the benefits make it worthwhile. Here are five strategies to consider.

    Reply
  10. Tomi Engdahl says:

    How Kubernetes became the solution for migrating legacy applications
    https://opensource.com/article/18/2/how-kubernetes-became-solution-migrating-legacy-applications?sc_cid=7016000000127ECAAY

    You don’t have to tear down your monolith to modernize it. You can evolve it into a beautiful microservice using cloud-native technologies.

    Reply

Leave a Comment

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

*

*