“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.”
‘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
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.
In preparation for his DevOpsDays Atlanta talk, Josh and Coté (well, mostly Coté) talk about the relationship between microservices and DevOps. They use the CAMS framing to go over how microservices could provide the architectural requirements to make DevOps possible.
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”→
You don’t hear too many stories about microservices in “normal” companies. In this episode, I talk with Nate Foreman about microservices-driven work he’s been doing with a large enterprise recently. We discuss the goods and the bads of this approach and, overall, how it’s working out. It’s a good discussion of how all the usual “cloud native” concept actually play out in the real world.
(As you can guess, it’s not actually an “action figure” company, we just used that example to mask the actual company.)