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.
It was a pretty good episode:
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.)
Show-notes and Links
Pretty good benefits/problem list, plus commentary on the “autonomy” angle.
When you can pay the sprinkler repair guy by using your finger to sign an iPad, things are looking up. Maybe it means we’ll have lots of microservices wrapped around government services, who knows. Also, we cover the strategy of choosing boring technologies, MongoDB, and The EMC Federation.
SPONSOR: Take our awesome, multi-cloud PaaS for a test-ride. Get two free months of Pivotal Web Services. Whether you want to deploy on-premises, in a dedicated public cloud, or just keep using our PaaS, Pivotal Cloud Foundry has everything you need for doing cloud-native applications. Go to cote.io/pivotal for the sign-up code!
- If you like video, see this episodes’ video recording.
- IBM’s all about Mac laptops – What about Lenovo?
- IBM Mobile Innovation Lab Examples.
- Software is awesome – Jobber.
- Whatever happened to the API Economy?
- Choose Boring Technology – “Adding technology is easy, living with it is hard.” – “Don’t chose tech because of testimonials on Hacker News. Hacker News is kind of like Fox News and not just because it’s dominated by libertarians.”
- What’s up with MongoDB?
- Will EMC spin-in VMware? – Not everyone’s familiar with the EMC Federation, I’m not familiar with anything like it in the industry. EMC, VMware, RSA, Pivotal, VCE
BONUS LINKS! Not covered in podcast
- Brandon: (Once again…) Wool
- Matt: Girl Talk videos one and two.
- Coté: Leading the Transformation, Applying Agile and DevOps Principals at Scale – good overview so far of what management at larger companies can do to introduce Agile and DevOps.