Microservices - State of the Art ( Clue - it's ripe for Bangalore-ing)

All this stuff is stuff gleaned off Goto conf videos (  go to/see them,they're good  !! )

This first one's from Kevin Goldsmith talking about Spotify. Youtube link here
Among other things, it is mentioned that unlike typical orgs having a Dev team, a QA team, a deploy team, an infra team etc, the micro-servicey organization has all these functions served by a single team, which is responsible for a (preferably) single business function. That means the, say, Users team handles development, but also deploys to its own servers and does its own QA.
Point to note is that this is an American way of doing things -as in this makes a lot of sense to a growing business. A director in a large company might not want to have the many many teams under him dissolved, so large companies will continue to have multiple teams, or even roles until forced to, much the same way large companies did not do away with the waterfall model until they HAD HAD to, as in, all those doing "Agile-Waterfall" were fired and had to go to separate separate companies where no one practised "Agile-Waterfall" ,and they were forced to learn "Agile", which we wish they didn't.

  
  
Kevin G also talks about what a typical micro-servicey company can do. See below. We are no longer slow-moving single-focus behemoth with multiple layers of fat . We are a lean mean Rambo, keep give us something to shoot. We here being the Company, of course.


Senior BeardFace shows us what's happening in today's world of hardware


That's Fred George above, talking about challenges. Youtube link here
It's hard to take someone with two first names seriously, but Michael Lewis wrote a great book (Liar's Poker) , so I'll bite.
Remember how sometime when you had requested IT for a new server around the time Steve Jobs died, and last week your manager told you that we were going in a "different direction" - meaning you're not gonna get that server, and you stopped dreaming about increasing conversions/ traffic to your service and started leaving early to binge-watch Netflix ?
Your micro-servicey org is dead in the water if you don't trust your engineers to ask for and get servers at will. Containers like Docker ensure that the version of OS they use never gets auto-upgraded  to something that doesn't work, unlike the frequent sneak upgrades your office Windows or Mac laptops inflicts on you.
There's no protection against Docker versions not working with other Docker version though, except for diligence on the Dockerer's part .

Senior BeardFace also knows how quickly teams are delivering code these days
Or wishes they did. Maybe they do in California. Please don't show this to my manager.


Scientist BaldyBeard  compares and contrasts the Olde and New Worlds
This is a long and very informative talk on Microservices. Like much of this man's work, indispensable if you want to work in the industry. Youtube link here
Slide below points out the main features of one vs the other.
What is not seen here is that microservicey orgs have large jumbles of github repositories and many many services, or many versions of the same services , in various stages of completeness . Tread lightly if you don't trust your engineers.
The primacy of engineers is integral to a micro-servicey org, lacking which you'll quickly find yourself gravitating towards an IT-ish org following the flight of engineers, and then all you'll see is a large number of releases involving config-file changes until the project is replaced by newer one.
This is perfect for an offshore cost center, as opposed to an onsite profit center, hence the title.




Scientist BaldyBeard has a list of attributes by which the MicroService may be known
Again, an absolutely indispensable list.  Points 1-4 means small teams serving a business function with code. Let's not get diverted by the kind of conflicted thinking that comes with projects.
See this link for some grade A enlightenment w.regards to the manager-project-sociopathy
Point 3 asks to align business goals with jobs, and virtually no one will tell you that their business is not aligned to jobs. Gee
An automated deployment pipeline is invaluable, and helps bring team sizes down. So this will work only at a profit center ,remember.


After Amazon,  Business has changed forever. It's hard to imagine one kiloton of Java code showing you wares ,scanning warehouses,  taking your money , routing deliveries to you etc
but that's  the nameless faceless labor force of the future (which is actually today) .
And what Java can do on some non-unique electronics, it can do on some other.
Like Fire which needed to be  brought down from the Gods but spread like wildfire afterwards,
high-volume massively-scalable systems are changing everything , and their magic  will be available to everyone at the cost of a code monkey and a Docker container.
While PHP wrought the first true magic of e-commerce , Java will create centralized players absorbing the business of millions across the globe [1] (in a world of 7 billion, I assume only some millions have _money_) . Commodity hardware, commodity software and commodity programmers will make the technology ripe for cost-optimization [2] ( hello Bangalore !) where your flimsy bug-ridden codebase can be kept on life support for a hundred years by means of a highly tantric ritual of daily meetings and scheduled releases of one line changes in order to appease the Code Gods. And as the software arteries harden , business will move on to other sparkly new things.[3][4]

In part 2 of this series , I'll talk about what makes microservices different from a small hello-world Java program that you might write on your first day of Software ( answer - not much ).

[1]  Cue emergence of  a giant node 
[2]As the language of microservices become household terms, the pop culture will take over  -  the technology will spread faster than education - Java will see to that - and the system will stratify and harden - MBAs  will swoop in and all existing code will get shipped to Bangalore.
[3] Microservices will remain alive in Chicago, but I doubt they'll survive in the Valley.
 [4] It's time someone created a code-aware self-pruning , genetic-programmingy L-system of enterprise code.