NGINX has released an article entitled Adopting Microservices at Netflix: Lessons for Team and Process Design. For a high level article it reads well, but closer consideration suggests that it fraught with problems, not the least some rather simplistic panacea attitudes.

The top-level claim "design for speed, not efficiency" is confronted by the old adage, "more haste less speed". 'Speed' but itself is downright dangerous. Speed with reviewed process is effective and efficient. It's the difference between riding a rocket and driving a car. The former may have more speed but the latter, with its steering wheel, brakes, and gears - is the one which is more efficient in most cases. It's the method which allows better control. "Speed" is what you apply some of the time in some situations, not all of the time to all situations.

The suggestion of "put your infrastructure in the cloud" is likewise not so simple. Cloud computing, per byte, per watt, per CPU-tick, is more expensive than local hardware. It *has* to be, because ultimately the cloud relies on real machines. This comes into effect especially if that hardware is in regular use (i.e., your IT infrastructure!). Cloud computing is most efficient for ephemeral and developmental tasks. In those cases where it may seem be cost-effective as infrastructure (e.g., a company-wide adoption of Google services) this is the result of (a) economies of scale and (b) advertiser payments from your metadata. The article's example of deploying 100 servers in a couple of days in São Paulo is fine for a temporary solution. But at the cost of local hardware versus cloud instances, the former will replace the latter if they wish to be cost-effective.

The argument for a "high freedom, high responsibility culture with less process" is a good one, but misses the mathematics of the equation. Process (as has been shown empirically, time and time again) can generate a more effective and efficient workplace - but the curve is parabolic. Whilst standards make sens up to a point (e.g., "this is our letterhead") after a while the deadening hand of bureauracy reduces efficiency (e.g., "all emails are reviewed to ensure that they use active verbs, as per our style guide"). Process documents should be like good code - too the point, action-orientated, using the principles of object-orientated programming where every rule has both a state (what it is) and behaviour (what it does) and incorporates especially polymorphism (i.e., this process applies in multiple situations) and inheritance (i.e., this rule inherits these other rules).

The argument to "Replace Silos with Microservice Teams" is a one that has been raised many times in the past in a variety of forums. But to some extent silos are effective and inevitable, as they represent the specialisatist skills and responsibilities that each individual has - indeed, each individual is their *own* microservice team. One should not replace silos with microservice teams, but rather integrate silos into service teams; the thin glue of an API, to use the metaphor. A system which is entirely team-based, all the time, will end up with endless meetings and little production, but perhaps lots of good ideas. Which comes down to a better analysis of working out what teams and meetings are for, and when they should *not* be used as well as when they should.

The final proposal "Adopt Continuous Delivery, Guided by the OODA Loop" is again a better component and well recognised. The essential argument really comes down to offering rapid turnaround and versions based on more immediate requirements, rather than a slow turnaround where a larger number of features are integrated into a single release. Note however that the article does note that the monolithic delivery model "works well enough with a small number of developers (say, 50 or fewer)", which certainly would apply for most software and IT projects. But again, it depends on the context of what is being delivered, rather than the quantity of developers. For security protocols continuous delivery may not be the best solution.

Overall, I give it a C. Picks up on some major themes that have been appropriate to some extent in some contexts but hasn't
considered where they are inappropriate in others. It has cherry-picked situations and argued that they are universal.