The world of software development and architecture is forever changing and evolving—and this is a good thing! As we seek to find better, more efficient and higher quality ways to deliver software—we need to explore new ideas, methods and approaches.
Whilst there are never any “silver bullets” there are always methods we can use to improve and new design approaches that yield better outcomes and changes to our own mental model that create new options.
One such idea that is generating a great deal of thought and debate is that of microservices. The idea that software can be built from smaller, more well-defined, scalable and reusable components in the context to cloud architectures. Borrowing from a host of previous ideas, and introducing some new ones, microservices promise to provide a pathway to software that is easier to maintain, faster to deliver, and better to operate.
In this week’s episode, Simon has an extended conversation with Matt Stine, Platform Engineer at Pivotal. In this wide ranging discussion, they explore the “what” and more importantly the “why” of microservices. Note that this is an extended episode of over 40 minutes.
Matt & Simon will be presenting at the YOW conference in Australia in December about this very topic, and you can find session information here: http://2014.yowconference.com.au
PLAY EPISODE #8
- Subscribe to this feed
- Find more episodes of All Things Pivotal podcast
- Feedback: email@example.com
Welcome to the All Things Pivotal Podcast, the podcast at the intersection of Agile, Cloud and Big Data. Stay tuned for regular updates, technical deep dives, architecture discussions and interviews. Please share your feedback with us by emailing firstname.lastname@example.org.
Hello everybody and welcome back to the All Things Pivotal podcast. Awesome to have you back. I’m very excited that you could join us today for what promises to be a really good conversation. I’ll introduce our guest shortly; first, just quick introduction of myself. I’m Simon Elisha and I’m CTO and senior manager of filed engineering here at Pivotal for Australia and New Zealand. Far more importantly, I’m being joined by well-traveled, well-educated and well-experienced gentleman by the name of Mr. Matt Stine.
Matt, welcome to the podcast.
Thanks, Simon. I’m glad to be here.
Fantastic. Matt, you’re a platform engineer here at Pivotal. Give us a little taste of what that involves. I think before we started the call you are booking a lot of travel.
Right. Platform engineering is a rather strange role that I’m still struggling to figure exactly what it is that I do. We do many different things if you think about Pivotal hasn’t been around that long. When we started out doing this Cloud Foundry thing, we didn’t have just a whole lot of field enablement at the time. When we had a customer engagement, we needed to have a meeting, we went. When we needed to write a blog post, we wrote the blog post. When we needed to do a demo video, we did it. Those roles have all evolved and things have started to travel away from us.
These days we focus on a couple of primary things. One of which is doing a lot of traveling around to do the Pivotal roadshow, which is an interesting all-day Pivotal Cloud Foundry-focused event where we do hands-on labs and presentations, presenting what the whole Pivotal story is around Cloud Foundry but also why we think it’s important for folks to engage in it. We do a lot of talk around continuous delivery, a lot of discussions of Microservices, which is what I think we’re going to focus on today.
We also get to do really interesting bleeding-edge R&D-type projects with customers. We’ll have a customer come to us and say, ‘I want to use Cloud Foundry like this,’ and we say, ‘We haven’t done anything quite like that before so we’ll take a platform engineer and put them in that situation and work side by side on this project.’ Sometimes those things turn into something that we later productize and sometimes those things are just leave behinds with that particular customer. In either case it ends up being a lot of the really challenging, interesting work that’s off the beaten path from what we normally do which is quite exciting.
Absolutely. It’s often a difficult stuff and hard stuff that use the best learning experiences and the lessons that you can share with other people that’s a lot of work what you and team do. I guess that helps us lead into the topic of the conversation today which is we’re going to be talking about Microservices, which is very much a topic to jure in a software architecture and design circles.
Certainly, I think Matt is a conversation that I would have preferred to have a beer at the same time because of that kind of conversation. Through my poor planning I’ve not delivered beer unto you on your end and certainly I’m lacking in Guinness] mind so we’ll have to do it without that.
I thought it would take a bit of a broader ranging discussion. Today’s podcast will be a bit longer than the normal one and that’s a good thing because we’ll be out to get into some depth. Maybe let’s start by defining some terms. How about let’s talk about a definition or otherwise of what a Microservices is. How would you define that, Matt? What do you think is the agreed upon or the common definition that’s being used?
My go-to definition seems to be a lot of people’s go-to definition is this idea of building an application service. When I say application service usually I’m talking about a web service that presents very often arrest API of some sort, but it could be other things that does … If you borrow the Unix phrasing a little bit, one thing and one thing well. The thing that becomes interesting is when you hear the word Microservice. It’s actually a term that I think is a little bit unfortunate because when I hear micro I immediately start to think about size and I immediately start …
Funny how you do that.
I start to think about size in terms of things like how many lines of code should it be or how many operations or endpoints should it expose, all sorts of things like that. Ultimately, you go down that road and you start to get into artificial boundaries that maybe won’t give you the results that you want.
What it really I think breaks down for is when I’m talking about what that one thing is. It feels like it’s focused on business capabilities, like I need to delivery the ability to do things about product inventory or do things about searching products or do things around recommending products based on products that other people like me have bought rather than massing all of those into a single system creating services.
These are kind of individual capabilities and in many cases they have and this is where I really think it gets interesting is they view the data that the organization is maintaining maybe a little bit differently. You start to have discussion about what is the data and domain look like for the entire business and then are there concepts in that domain that maybe different business units think about a little bit differently and maybe we start to borrow things from domain-driven design that Eric Evans popularized with his book.
There’s this idea of a bounded context that starts to feel like a really useful tool to say, ‘Microservice is just a service that presents the operations necessary to operate within one of these bounded contexts where I take this set of terms into this context, I mean this very specific thing.’ I like to use the example of a movie distribution company, which is starting to become a little bit anachronistic. It’s something that I … It’s a domain that I’ve worked with as a teaching example for a long time.
I might have the concept of movies mean in a product catalog setting. It’s a movie and it has actors and has a title and it has a genre associated with it. Then I go into an inventory context and I’m really thinking about physical pieces and media, DVDs, Blu-rays. I have a certain number of each of them and I have them in certain locations, some are in circulations, some are not. I could if I was designing a system. You take all of the possible definitions of movie.
I’ve had the same conversation with several different customers. One recently was an airline and there the concept was reservation. You would think we would agree about what an airline reservation is, but you get into that domain you find out there’s actually about 15 or 20 different definitions of what an airline reservation is. Trying to make one service actually encapsulate all of that knowledge and all of the operations necessary to govern that knowledge is.
I think we would all start to agree that maybe it’s necessary but it’s difficult. Of course, I would argue this is not necessary so then the first thing I see people do is we’ll break up all the services but we’ll keep all the data in a single data store and that brings a whole set of problems to the table. Then I say, ‘Really what you want to do is actually cut the whole stack,’ and say, ‘Microservice isn’t just an app that I deploy but it’s also a set of data that that app governs and everything comes to that API layer and we stop this business of integrating the world’s knowledge at the level of.’
It doesn’t matter if it’s a relational database or one of the no-SQL stores because you put too much of anything in one store, you just start to run into the same complexities. In fact, I would think the relational model in some cases gives me better tools to organize a bunch of disperate concepts than some of the no-SQL stores do it and turn out to be quite a bit messy if I were to that and some of these scheme-less databases.
Long nuance definition to what it seems like a very simple question and I’m not even sure if I defined it yet.
I think it’s one of the things. You start to define it by what you do with it and you raised some interesting points. We’re going to move on to the why because the why is probably much more important than what it is but that concept of context becomes really relevant and bounding that context is such a way that you can control what’s happening within that element. This dives into the whole concept of Agile and delivering software on a regular basis, keeping that within a reasonable bound of control.
We’ve probably all lived through the world of trying to create this overly massive database, the single social truth that deals with everything it solves all the world’s problems and all the world’s ills. We know that it certainly had scaled. That’s breaks down pretty spectacularly and becomes almost impossible because everything becomes a tradeoff.
Just as you said if I’ve got 17 different kinds of reservations but I have to find one way to represent it, I’ll have 16 people who’ll be disappointed or 17 people who’ll be disappointed because all their representation did not get represented the way they want to see because of all the compromises made for everything else.
Your ability to please the constituents falls away very dramatically so not having to be so totally bound to one view of the world gives you some options, also provides some challenges as well. Certainly, it gives you a step into a more resilient and robust architecture and maybe that’s where we can jump into that.
One of the things that have really fills me around the Microservice architecture is how well it does help into this concept of building anti-fragile, robust fault tolerant and in way fault-expecting services. We talked a little bit about how the scope and capabilities deploy these components in small increments fit into that path.
I think it might be useful if we spend a minute or 2 talking about what this whole concept of anti-fragile even means. I guess there’s the book and too fragile that I can never pronounce Taleb’s name correctly.
Taleb is the word.
It’s okay when I write it down because nobody knows I’m pronouncing it incorrectly in my head but we’re on a podcast now so I allowed you to butcher it so but anyway.
He asked this interesting question, what is the opposite of fragile? We naturally will answer something like resilient or robust. Something is fragile that means when bad things happened it’s going to break so I’ll make something that isn’t going to break when bad things happened. Then he says, ‘Wait. Actually, you’re wrong. If fragile is something that breaks when bad things happened, then the opposite of fragile should be something that improves when bad things happened.’
It takes you a little while to think about what is a system that has ever existed that when bad and crazy and stressful things happened actually gets better and then you start to … You see this example of the human immune system that it’s like, ‘If we never get sick, then we encounter some pathogen and our body doesn’t know what to do with it because it’s never been trained properly to deal with these scenarios.’
We even joke sometimes as parents that we actually want to get our kid sick a little bit to actually help them build up. Then he says, ‘All of these treatments that we do is like the doctors who will prescribe you antibiotics every time you get a sniffle you actually weaken your ability to handles these things and at the same time you end up creating even more resistant strains of the bacteria or viruses themselves,’ and so we end up thinking we’re fixing the problem and we’re making the problem far worse.
Then you think … Go ahead.
It’s interesting too because it really is a mind-shift change and it’s a hard mind-shift change, particularly for us folks coming from an engineering background because we tend to look at problems inside. I can fix this or I can make something work and I’m think every possible thing that could go wrong and I’ve counted it. I’ve got the exact rectification or I’ve got the durability I want or the clustering, whatever is the step. I want to take the golden screwdriver approach to engineering.
Inevitably, stuff happens that we don’t expect and we haven’t considered. Until you move that mind-shift set of saying, ‘I can predict everything that could possibly happen to this system,’ and say, ‘I have no idea what could be happening to the system, what the future holds and I’m open and I’m okay with that and I will now design accordingly.’ It completely changes your perspective on the problems they made and you stop in a way throwing stuff at the problem, the temptation just throw bigger hardware or more expensive hardware or this particular language because I know it will do this, it will do that. It changes your mental model.
I think that’s a very important entry point in terms of thinking about anti-fragile. It’s a mental change in the way you look at problem they make.
I really agree. I guess one of the ultimate realizations of that model which dovetails nicely with the conversation around Microservices is you start to think about the Netflix architecture. While they’re very popular right now for their discussions around Microservices near architecture, Adrian Cockroft is speaking at great length about the things that they did while he was at Netflix before he moved on to Battery.
They were actually first I think becoming a bit famous for the strange thing called Chaos Monkey and the Simian Army so they do this wild and wacky thing of … In my production environment, I’m going to turn loose a process whose sole responsibility is to randomly introduce failures into my architecture. As a long time enterprise information technology professional, I look at that and think, ‘Oh my goodness, that’s insane. I’m doing well just to keep things up without breaking things on purpose and you’re telling me that I should actually break things on purpose.’
Why did they do it? They do it so that they can actually determine where the system has weaknesses and address those witnesses. It’s just like exposing myself to germs in order to give my immune system something to practice with. I’m actually exposing my system in a sense to germs to give it something to practice with, which is just a radical concept. Then you look at Netflix as systems and they haven’t been completely immune to failures but for the most part as failures have occurred especially in the underlying infrastructures, they faired quite well.
Exactly, exactly. Often I told the companies out there. I came from a background of working in DR in high availability, etcetera and often I had the conversation with the customers who are very resistant to doing tests. We’re not going to do a DR test. Outside them if you’re not willing to test the system in the best possible circumstance whenever on a random in the middle of the day, what possible confidence can you have in it working in the worse possible time when no one is around which is when these tops of problems surface.
It’s interesting until you make that leap and say, ‘Yes, we’re going to test all the time. We’re going to expect failure all the time.’ Your behavior actually goes against you.
Something we probably haven’t done a good job so far is saying, ‘We want to be anti-fragile.’ How do Microservices help me become that? What elements of the Microservices architecture fading today?
I think of it in a couple of ways. If I have a set of business capabilities that I’m trying to deliver and I have those bound up in a single monolithic component that I’m going to deploy and one of those capabilities suffer some failure mode or starts to behave badly, it has the high likelihood of inducing cascading failures and actually bring that entire system as a whole and now not only did you have 1 business capability misfire you have all of your business capabilities misfiring and that can be quite catastrophic.
It also can be quite difficult to recover from as well as figure out what actually cause this failure in the first place whereas when we start to deploy capabilities as independently deployed Microservices we are going to have to deal with some complexities maybe that we haven’t did encounter before. We start creating distributed systems. There’s a whole list of things that we now have to be aware of distributive systems that we didn’t have to consider before and that’s the set of challenges that maybe we could talk about later.
Let’s just assume that we have these individual capabilities deployed. If one of them fails then I can limit the failure affected by the system by, A, isolating those capabilities in different services but then, B, at the boundary between let’s say I am a service and I have some dependencies, the boundary between me and all of my dependencies I start to use patterns like for example the circuit breaker pattern that Mike Nygard wrote about in his book Release It.
Then the story goes that Adrian Cockroft took that book and walked around Netflix and distributed copies and Netflix went about, ‘This is good stuff. Let’s create our own circuit breaker,’ and now puffs this framework called Hystrix over time that you can leverage in your applications to insulate you from your dependencies and prevent these cascading failures from happening. You now have a situation where you can fail.
It’s actually not a bad thing to fail because you have prevented any one failure from inducing a catastrophe across the entire system but you’ve also … it built in graceful fallback behaviors when anyone of these failures occurs. Instead of spitting back a nasty 500-server error or something like that to your users, you actually maybe think about the book or product page on Amazon. You go and you see product information but you also see people rated the product these many stars and we have these reviews and we have these recommendations and the recommendations that service is down.
Maybe the recommendations just don’t show up on the page that time. If I’m just there to buy a book, I probably don’t care and I may be don’t even notice. There was a failure in Amazon system but they got buy and they actually successfully converted the sale without that failure causing any real problem. I think that’s one of the real benefits that you get in Amazon.
Of course, has employed this Microservices’ style for quite some time in the bookstore and actually had the benefit. I was in Seattle this past weekend giving some talks around Microservices. I had 2 former Amazon developers in the room and then we started … I was talking about exactly that page and telling that story and I said, ‘How right am I about this narrative?’ They said, ‘You’re actually pretty much exactly right on.’ There’s a whole order of magnitude things behind the scenes that you’re not talking about there also going on but the story is pretty correct.
It’s true. Being ex-Amazon myself I know Werner would often talk with customers about the number of services that make up that front webpage you just see as amazon.com. There are hundreds of services happening behind it. You don’t see a big gaping gap in the paid room when one of the services is done you just see a different one.
Really it comes down to that perception of failure and perception of operation is that you want to be like this one. You’re looking graceful and smooth across the surface but underneath the legs are going like crazy and really it’s a case of allowing your customers to interact with you as a business without seeing the complexities of what’s going on behind the scenes. In fact, it’s one of those you had to bring the bank for some reason the other day and I got that commenting. You probably get that yourself when you ring a call centre. The systems are running really slow today. This isn’t working. Why do I need to know about that? That’s not my problem.
The systems are where it shouldn’t affect us. Any conversation Microservices can go many, many ways and we don’t … Where should do you want to spend all they talking about but, again, the lack of bear is going to prohibit us from that. I think there’s a few elements that I just want to touch on that I think are relevant to this conversation that people need to be aware of. Again, these are jumping off points when you start this journey.
There are concepts or things like stateless design of applications, so looking at way you store, stores of statement where you did not that have a direct impact on, ‘You can build this Microservices,’ and how scalable they may be and how easy they are to change. There’s also a whole conversation around continuous integration and continuous deployment. Because we’re delivering smaller amount of software, we should be able to deliver them faster, but to do that we need a strong sense of automation when you say it meant to make that a regular feature of what we’re doing rather than saying, ‘I’ve got always little things I have to manage in my time independently.’
Absolutely. In fact, usually, my starting point in the whole Microservices discussion is around this idea of continuous delivery. I think again back to a very short interview that I watched that Adrian Cockroft gave about Netflix. He makes the startling statement that we really didn’t want to build the Microservices architecture. What we really wanted to do was we wanted to out innovate our competitors which meant we wanted to go really, really fast while simultaneously being able to go really, really safe.
We’ve already talked about it a little bit being resilient to failure. You can get in a car and you can hit the gas and you can go really, really fast and you’re probably ultimately going to end up having an accident. Something bad is going to happen so you need to be able to go fast and safe, which is why going fast on a bullet train is so much better than going fast in a car. At least until a Google finishes up the self-driving cars and then maybe we’ll fix that problem.
They started thinking about, ‘What type of an architecture is going to allow us to go really, really fast and innovate and drive things out?’ it’s almost this idea of let’s stop trying to control the world and start allowing small teams to innovate around small bits of functionality that are going to deliver real business value and just allow them to iterate and deploy and go as fast as they can but also have strong testing discipline.
Not just testing of functions but the amount of analytical testing that they do. When they deploy a service and determine how are customers interacting with the service and is this behavior better or is this behavior better. The AB testing or A, B, C, D testing are just the number of level that they go and it’s quite remarkable and you just can’t accomplish that. When anytime you want to make a change, you have to line every one up, come to a point of stability, run through a long regression cycle and then finally deploy something.
By the time you’ve done that, the thing you are trying to change is no longer relevant. Someone’s passed you by and so that’s to me one of the strongest, most important value propositions behind Microservices is. In this world where it seems like if you’re not turning software and information technology into a profit center rather than a cost center and actually really driving innovation in software is the heart of how you do business then you’re going to lose.
If that’s true then we need to figure out how to actually go faster. It seems like this architecture has arrived at the same time we’re starting to have these conversations about continuous delivery and DevOps and really operationalizing and productionizing and gaining real-time insights from how applications are behaving. All of these are converging at one point in time and you’re starting to see really interesting things happen. I think one of our goals is to help people in the old school enterprise, if you will, start to take advantage of these same things.
Absolutely. It really is a chance to steep up and steep up with capability and it’s a steep up of that closely cycle of thing. We’re going to create something, deploy something, operate something, see how it’s going and improve it. This is continuous improvement that manufacturing has been across for a long time. We’ve got lot of things that we can learn from there to have a better software deployment approach that we intend to take to something that’s far more scientific as well as being far more quick in terms of working in an effective basis.
It’s interesting. We talked about moving quickly, etcetera. People often struggle with what is that capability of pushing into production that I want and what happens if I break something, etcetera. If you preconditions here that we need to say, ‘You need to be this high to ride this train,’ firstly, concepts like really strong API boundaries around services are super important so that you can change any of this behind that API, so you consider any decent web service you’re using today on the internet.
You don’t know if it’s being powered by a steam train, a super computer, a barrel of monkeys, you have no idea. You really have no idea and nor should you, which means that the provider that service can make a radical changes of underlying deployment of that seamlessly. They can only do that if they’re operating on a platform that lets them do that reliably.
Having that entire process locked in in terms of how I move through development test, integration then deployment, then the ability to deploy seamlessly roll back if there is something critically wrong. Also as you mentioned have the telemetry implied to understand the new system that I put in is it better or worse. It’s like when you visit the optometrist and they do that thing with the eye test and they show you 1 lens and say, ‘Better or worse, better or worse,’ and they keep changing and you’re going, ‘I’m not sure.’ You want to be sure if what you put in was better.
This concept of delivery becomes really important. There’s a few approaches I was saying out there and it’s interesting. What you’re saying too is one is limited as to what they can do whatever they want as long as their API is not so strong. I’ve seen other approaches where people will have a really regular release train so every week, every couple of weeks and they can tag on to that train and I’ll know if their awesome dependencies they have they can’t rely on being place or not in place, depending on the train.
What are you saying in terms of people who are deploying frequently? What are some of the approaches that seemed to be working?
I think both of those show-up show up a lot. I think I’m a little bit more exposed to the former in terms of companies that are actually trying to do these themselves and build services and operate them at least those that I think are being most effective with it. I see more of the release train style show-up. It’s actually interesting when it’s the way that we shift Pivotal CF and the associated services is that we need to … It’s different to run software yourself than it is to shift software that someone else is going to run.
There’s a whole other set of complexities there and so there’s a point in time in which we need to ensure so much as we can that all of the things that we’ve built and all of these disparate teams delivering their own services that they all worked together so that when our customer downloads them and spins them up in their own data center that they actually get positive results. That release is super effective for taking a Microservices architecture that’s like Cloud Foundry. That’s one of the things that I think people are sometimes interested in that we dog food our own architectural advice in terms of the way that we define systems.
A lot of customers are coming to me. I had a couple of conversations this week with folks that were interested very deeply and, ‘Okay Pivotal. How is it that you actually deliver software and keep it running?’ We know that Cloud Foundry is great. We know that all of these data products are great. How do you actually keep that alive and keep it going so things like release trains come up in that world?
There is a certain sense in which you do need to, again, all line up to make that work. I think the ultimate is when the only person I have to line up with is myself and I can just deploy whenever I want to then that API contract. I had a very fascinating conversation yesterday with Elisabeth Hendrickson. She’s one of the directors of quality engineering here at Pivotal Labs. We were talking about what is it take to test Microservices and what was the focus of the discussion.
A couple of things. One was obviously this idea of contract that there is some contract that my service provides that other services that are in effect customers of my service can depend upon. There’s all sorts of interesting nuance there and interesting thing that she brought up is not just the business contract. It’s how is the service going to behave when it encounters failure modes and some of those things might actually be part of the contract.
How is the service going to behave when other services start throwing bad information at it or they get into a state where they start doing what ends up being a denial of service attack on my service, how is my service going to behave and that could be part of the contract.
Then she brings up this idea of what is the trust boundary around components; where do I draw the line of I can trust that this thing is going to behave properly so maybe I don’t need to have as robust of a testing infrastructures around it, but then there is going to be a boundary that I get up to where I cross that boundary. Anything that happens outside that boundary, as we’ve already said, we can’t predict what the world is going to do.
When I get to that boundary, I have to start thinking really deeply about what is my risk tolerance to things that are going to happen and how many of those things do I have to be very resilient against when the opposite of what I want to occur actually occurs.
Then there’s 1/3 level that I think is interesting. This didn’t come out of our conversation but it’s come out of the conversation that I’m watching on the internet is this idea of consumer-driven contracts. What basically that is I think the best explanation of it I heard from Neal Ford from ThoughtWorks. He said, ‘Basically what that is is my customer gives me a set of unit tests.’ I add those unit tests to my test suite so that I don’t just say I’m abiding by the contract that you expect. I actually have your tests that prove I’m abiding by the contract that you expect.
You can take that further and there are all sorts of interesting things where you can have a single artifact that defines the testing components for both sides of the relationship and you can guarantee. If they both meet the same contract so it’s okay. I think maybe there might be some situations where I actually introduces more complexity than the payoff that’s associated with it.
The ideas and the things that we think about now that maybe we didn’t think about before I think are very interesting because it almost feels like we’re less concerned about individual components than we are about, how the system as a whole is actually going to behave, which is ultimate what our customers are depending upon is, what is the aggregate behavior of the system and is that behaving within normal expected parameters.
Exactly. There’s a tolerance. I think we’re moving away from that boundary experience of system up, system down. I can transact, I can transact. As a customer, I can get what I need, I can get what I need. There are now degrees within that and that’s why this is becoming very powerful is that I may not get all the features that I want but as we know with most softwares that we use, we may be using 20 percent of what’s in there anyway.
If there is something affecting the other 80 percent, I don’t really care as long as I can continue with my day I’m good to go. Again, decomposing these systems and making them truly the sum of their path, it means that when certain components are affected by bugs or failures or the unexpected you’re entire customer base is not necessarily affected. In fact they don’t notice but to get to that point and I think that’s what we’re getting to is you have to have a degree of sophistication, you have to have platform, you have to have toolset and you have to have the right cultural outlook to deliver on that vision if you like.
What are your thoughts around team culture and development approaches in the way we think about this domain that work for organizations that are looking to move to a more Microservices-focused approach?
I think ultimately it’s just a natural evolution of the whole DevOps conversation even that you can trace back to some of the original Agile conversations, which is this idea of backing off of specialization a little bit. We don’t eliminate specialists but we back off of this idea of creating the silos of work where we lump all of the database people together and we lump all of the programmers together and we lump all of the testers together and all of the assistant administrators together.
Then we expect them to work effectively together, but we create these walls between them and we create these different management structures and toolsets and disparate vocabularies even so far as conflicting incentive structures. Then we expect the good things to happen which is it’s odd when you actually step back and you think about all of the barriers that we’re putting in place to create an end product that actually works well when all of these pieces do their part.
Of course, one of the primary points of the original descriptions of Agile teams were cross-functional teams and small teams and self-organizing teams. Then we get into DevOps and we see those same ideas starting to emerge from not the development side of the house but the operation side of the house. Ultimately, to me it is just converging on this idea that we do have sense of the system that we want to deliver as a whole. It can’t just be complete chaos in the Wild West and everyone doing their own thing.
There is a sense in which having shared responsibility at the capability level for understanding what you need to build, building that thing, testing that thing, running that thing, wearing the pager at night so that when things go wrong you wrote the code. If you wrote sloppy code, it does not behave well. You’re the one that’s going to get woken up in the middle of the night.
It really starts to change a lot of the behaviors that we engage in and we start to focus on shared goals and goals that make sense as opposed to optimizing for developers just want to ship code and system administrators want to stop me from shipping code because when I ship code I break things. We get out of that dysfunctional mindset and I think Microservices turn out to be a fairly interesting point around which we rally those same ideas of not just changing the way we do things technically but also changing the way that we do things organizationally. I think if you don’t actually do both, you’re probably going to have a lot of problems with the one that you didn’t decide to do.
Agree, agree and you’re right. I think that the conversation around Microservices is a catalyst to changing a whole of other things and very much intensive organizational structure that needs to be both that big picture of vision of where we’re heading, what’s the other thing we’re trying to build.
Then these very broad running rule and guidelines to say, ‘Here’s where I want to hit you to head.’ Here’s the kind of behavior I’m expecting but we’re not going to micromanage you. We’re not going to micromanage your team. Your team is empowered and has the authority and capability to deliver the way you want to deliver, to operate in the way you wish to deploy, but it has to mission with the whole in terms of quality, in terms of timeliness, in terms of those very strong contracts, etcetera.
We all want to get along to work together and I think it’s a very powerful change. When you walk into an environment where they’ve made that change and they’ve changed their culture and they’ve empowered their team, it’s so refreshing and exciting. By no means it’s perfect because nothing is perfect. There are no unicorns out there but it is a world of difference to the 6, 12, 18, 24-month death marches that I’ve lived myself, where you’re just sliding away every day, cutting card, you never see any results, you never know that the opposite guys are doing, the deviates they want to talk to you, their system not made.
This is a far more healthy widely interact and really, again, extends that capability of an organization to deliver software, to deliver functionality into the hands of their customers to actually do their business which is really when you boil it down what it’s all about.
That’s right. That’s absolutely right.
We’ve been going on for a while now. It’s probably time to wrap up but there’s lot of jumping off points to talk about in the future and surely we’ll hopefully Matt we’ll get you back on the program, again, talk in more depth about some of these particular areas. How does that sound?
Sounds I’ve had so much fun. I didn’t even realize how much time has gone by. I get into these conversations and they sometimes go on for hours. Obviously, not sitting in the office wired up to a headset but things have to be done in certain way when one of us is I don’t know how many time zones away from the other.
I don’t want to count. I don’t want to count. Certainly, we’ll have to try and tier up. We’re in the same hemisphere at one time. In fact, actually, I can promote this that I should have thought about doing earlier.
Matt will be coming down to Australia. This is for my local listeners. We’ll be coming down to Australia for the YOW Conference in December in both the Sydney version and Brisbane version. I’ll be practically playing the role of Matt in Melbourne version so I do play on you on TV Matt!.
See him in the flesh talking about this very topic around Microservices at that conference so that will be good. We may have been managed to sneak in a live conversation that we can share with the podcast listeners as well at that time.
That would be fantastic. I’m looking forward to that trip so much. I’ve waited so many years to travel significantly outside the US. I did go to India a few years ago to do some training with the team I was working with. I finally made it to Europe for the first time in London and Paris a few weeks ago and now I get to go to Australia, which is going to be absolutely fantastic.
We’re certainly excited to have you down here and sounds like you’re collecting some good stamps in the past which is always a nice thing.
For the storytelling.
Matt, thank you so much for joining us and thanks everyone for listening. I hope you’ve enjoyed this more extended version of the podcast. We look forward to doing many more of them for you. Again, if you have feedback, email@example.com. You can visit us on the web as well. Please do tell others if you enjoyed in the podcast. We want to get the word out.
Thank you again for listening. Thank you, Matt and see you later. Keep on building.
Thanks for listening to the All Things Pivotal Podcast. If you enjoyed it, please share it with others. We love hearing your feedback, so please send any comments or suggestions to firstname.lastname@example.org.
About the AuthorMore Content by Simon Elisha