Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
Numărul 107
Abonament PDF

Microservices, interviu cu Sam Newman

Ovidiu Mățan
Fondator @ Today Software Magazine


How do you see the difference between SOA (Service Oriented Architecture) and Microservices ?

They are not different things. Microservices are an opinionated subset of SOA. SOA just describes a system built out of collaborating services. Microservices is a type of SOA, which is more opinionated - it’s “prime directive” if you will is that microservices are independently deployable. So think of microservices as a type of SOA, in the same way that XP is a type of Agile.

Regarding the size of a microservice, you mentioned in your very known book: Building Microservices that it should be "as big as my head", based on James Lewis affirmation. What did you mean ?

This version of “size” speaks to your ability to comprehend what the microservice is doing. It’s just one measure you can use, but if you are unable to understand what the microservice is doing, it might be too big! The problem of course is that people have “different sized heads” - which is to say someone familiar with the system may better be able to understand what a microservice is doing than someone brand new to the project. Likewise a more experienced developer might more quickly understand what a given microservice is doing, compared to someone newer to the industry. So it’s far from a perfect measure. 

Moving to a microservices approach is also changing the company’s teams structures?

Microservices work best where you can tie back ownership of a microservice to a specific team. So one team might own more than one microservice, but each microservice should be owned by exactly one team. At a basic level, you may need to change your organisation to move away from more collective ownership models (anyone can change anything) to stronger forms of ownership.

Going further though, microservices can help you move to organisational models like those outlined in the Team Topologies book - steam-aligned teams, with end-to-end responsibility for building and running an application. 

Your affirmation "microservices are a poor choice for an organization primarily concerned with reducing costs" is something that some of the IT managers should be looking before going into today's trend with microservices. Please explain us why it will be more expansive.

It’s pretty simple. Firstly, you will likely need new infrastructure, and new tooling to manage that infrastructure. Secondly, learning how to build and manage a distributed system is hard. This will take time and energy. This will in turn reduce the amount of time and energy you can put into new features. So you’ll either have to be satisfied with a slower delivery of features, or else having to try and add people to offset this problem. Microservices *might* reduce costs in the long term though through driving other efficiencies, but this is likely a long way off. If your primary motivation is cost reduction, I’d consider microservices to be a bad choice.

Microservices and startups - what's your recommendation ?

Probably don’t do it. At the start of a new project, we often don't know exactly what we want to build, nor do we know if it will be successful. We need to be able to rapidly experiment, and understand what capabilities we need to build. If we tried building for massive scale up front, pass:[\we'd\] end up front-loading a huge amount of work to prepare for load that may never come, while diverting effort away from more important activities, like understanding if anyone will want to actually use our product. Eric Ries tells the story of spending six months building a product that no one ever downloaded. He reflected that he could have put up a link on a web page that 404\’d when people clicked on it to see if there was any demand, spent six months on the beach instead, and learned just as much!

I expand a lot on this here: https://samnewman.io/blog/2015/04/07/microservices-for-greenfield/

What's coming next after microservices and we should pay attention?

After? Who knows? Microservices arguably are just a continuation of a lot of old ideas. They’re a rediscovery (for some) of modular programming (which we’ve been doing since at least the 1960s). I would hope that people who are deciding against microservices would consider building modular monolithic applications instead. 

In terms of general trends, expect Kubernetes to continue to be in more places, but increasingly expect you not to notice. It’s not developer friendly. Abstractions like FAAS will hopefully become more common, allowing us to hide away that detail.

Tell us few words about your presentation from The Developers conference: Hiding the lead Coupling, cohesion and microservices

This talk is all about looking back at concepts from and 1960s and 1970s which related to how we organised our code. Microservices are a modular architecture, albeit one with the added complexity of being distributed systems. The upside though is that we can take a lot of prior art from structured programming and elsewhere and apply it in the context of microservices, to make sure we actually deliver on their promise. Even if you aren’t building a microservice architecture, or have no interested in doing so, there should still be some concrete takeaways for all attendees.

NUMĂRUL 138 - Maps & AI


  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects