“It’s 2019 so apparently everyone has a service mesh. Istio has been the most hyped – it has solid corporate backing from IBM, Google, Pivotal and SAP. These companies now need to do a better job of nailing use cases.”
HashiConf EU 2019: The Service Mesh push and Progressive Delivery
“The software serves as a management mechanism for distributed microservices, providing capabilities like traffic management, service identity and security, policy enforcement and telemetry among apps running across multiple Kubernetes clusters and hosts.”
Original source: Istio sets sail as Red Hat renovates OpenShift container ship
“Briefly, microservices is a service-oriented software architecture in which server-side applications are constructed by combining many single-purpose, low-footprint network services. The touted benefits are improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy. The opposite is a Monolithic architecture, where a large amount of functionality lives in a single service which is tested, deployed, and scaled as a single unit.”
That’s a good definition!
Original source: Goodbye Microservices: From 100s of problem children to 1 superstar
Original source: Managing Data in Microservices
‘The traditional server request/response model for computing comes from an imperative programming model, though an events-based model really is more of a functional programming model, she noted. “Functional programming models work really, really well for distributed systems,” she said.’
Original source: Microservices: It’s All About the Events
Also, a long section on matching your culture to the stuff.
Original source: Should that be a Microservice? Keep These Six Factors in Mind
There’s some good “how do I actually get my organization do all this unicorn stuff” comments in this interview with DreamWorks Animation’s Doug Sherman.
Here’s one sample bit on winning people over to microservices. Instead of going into the lab for six months to work on a tool that they think will be useful, they do a lot more user-driven work upfront and then do (it sounds like) weekly small batches to keep the users apprised of the tools and, you’d guess, give continuous feedback:
You have to understand what people want to do in their domain. In the past, Ive gotten it wrong. Ill come up with an idea I think is sound I think its the coolest thing ever and Ill work six months in isolation with my team, and then well do this big reveal. And every time we’ve done that, its gone horribly wrong, because 1) people feel like were lecturing to them, like we know better than them. And then 2) we would typically have over-engineered it! It would be like the 747 cockpit, you know? There would be this overwhelming amount of knobs and bits and pieces that I think are great to have, but from their viewpoint, they only need to do a few things, and thats an overwhelming amount of stuff to have to sign up to be able to do. So now, Ive gotten into a habit: before I even write a single line of code, I interview everybody that potentially will use the solution that Im going to write, and I keep them in lockstep with me and my team just about every week. We keep them engaged, helping to influence the direction Im basically trying to echo out in code all of what they want. Its gone so much better, because they feel invested. They don’t feel like in six months I’m revealing this big, mysterious thing. They feel like this is just something they’ve seen through iterations. And whats empowering about that, too, is if you can get the spiritual leaders of the different departments that you’re trying to encourage to use your solution, they’ll help sell it for you.
And then a bit on their progress:
Were about 50% of the way in having some amount of production coverage powered by microservices which are deployable in cloud containers powered by technologies such as Spring and Spring Cloud.
There’s more, good cultural change stories in the interview.
Breaking up the monolith with good, old fashioned, OO-think:
Instead, Vanguard has begun a journey to break apart our monolithic legacy systems piece-by-piece by replacing them with microservices over time. With a microservices architecture, we remove the business logic and data logic from our applications and replace it with a set of re-usable modules of code that are built and deployed as independent entities. We then compliment this architecture by chunking out our user interfaces into modular purpose-built components.
De-coupling for stability and resiliency, among other things:
This service-based approach to application architecture provides a variety of advantages over the jumble of code that defines a non-modular monolithic application. First, services reduce redundancy by making sure there is only one copy of application logic for a given capability – regardless of how many applications leverage that logic. In the long run, this leads to lower development costs and increases speed to market. Second, since these services are deployed independently and built in a resilient manner, outages in one area of an application are less likely to bring down an entire system. In some instances, several of our services can be down without our clients being aware of a loss in functionality thanks to the ability of our applications to automatically react to a service that isn’t available. Finally, services enable our applications to scale easier. The marriage of cloud and services means we can quickly spin up infrastructure to handle surges in the number of transactions we need to handle without needing to scale up an entire application.
Recently, I’ve been in conversations where people throw some doubt on DRY. In the cloud native, microservices mode of operating where independent teams are chugging along, mostly decoupled from other teams, duplicating code and functionality tends to come more naturally, even necessarily. And the benefits of DRY (reuse and reducing bugs/inconstancy from multiple implementation of the same thing), theoretically, no longer are more valuable than the effort put into DRYing off.
That’s the theory a handful of people are floating, at least. I have no idea if it’s true. DRY is such an unquestionable tenant of all programming think that it’s worth tracking it’s validity as new modes of application development and deployment are hammered out. Catching when old taboos flip to new truths is always handy.
Continue reading “Questioning DRY”
Pretty good benefits/problem list, plus commentary on the “autonomy” angle.