Revisiting Microservices With Matt Stine

January 6, 2016 Simon Elisha

sfeatured-podcastAbout a year ago Matt Stine and I sat down for a wide-ranging discussion on the “what” and the “why” of microservices. This is back when Matt was a platform engineer, working in the field with customers. Since then, he has published a book on microservices and moved to be a product manager for Spring Cloud Services for Pivotal Cloud Foundry, which packages server-side components of Spring Cloud projects, such as Spring Cloud Netflix and Spring Cloud Config, and makes them available as services in the Marketplace. Since most of his work has been around adapting contributed projects to a true Cloud Native architecture using microservices, in this visit, Matt shares some valuable lessons on what we see is working and not working—and what people should look out for.

PLAY EPISODE

SHOW NOTES

TRANSCRIPT

Announcer:
Welcome to the Pivotal Perspectives Podcast, the podcast at the intersection of Agile, Cloud, and Big Data. Stay tuned for regular updates, technical deep dives, architecture discussions and interviews. Now let’s join Pivotal’s Australia and New Zealand CTO, Simon Elisha for the Pivotal Perspectives Podcast.

Simon Elisha:
Hello, everybody, and welcome back to the podcast. Fantastic to have you back and a very special guest star day today. I’m joined today by Matt Stine in the U.S. You may remember Matt, we spoke probably about a year ago about microservices and at the time I think he was even doing a little bit of a different role as well.

Matt, welcome to the podcast and I’ll get you to introduce yourself as to where you are and what you are now.

Matt Stine:
Okay. Hey, Simon, how you doing?

Simon Elisha:
Good, thanks.

Matt Stine:
I am … See, where am I located right now? I’m actually at home. Last time we talked, I was on the road so..

Simon Elisha:
Yeah.

Matt Stine:
I’m at home now in the very close vicinity to Memphis, Tennessee, in the U.S. If you want to find that on a map, I’m actually a little bit down under the state of Mississippi there, but I’ve also, I guess, changed roles fairly significantly since the last time we talked. I think the last time we talked, I was still doing the platform engineering thing.

Simon Elisha:
Yeah.

Matt Stine:
These days, I am officially a Product Manager for a little suite of services that you might have heard of called Spring Cloud Services. I think you’ve talked about that at least once or twice maybe on the podcast, right?

Simon Elisha:
Yeah, for sure.

Matt Stine:
We decided to kick that effort off, almost a year ago now and I officially transitioned into the role that I’m in probably within two or three days of right now a year ago. Very interesting transition for me going from spending the majority of my time out in the field talking about our products and helping people use our products to actually being somewhat in charge of building one of our products, which is a completely different monster, I’ll tell you.

I’ve learned all sorts of things in that realm that I’m actually turning into a conference talk for the upcoming year called, “Confessions of an Agile Product Manager.”

Simon Elisha:
Awesome, that’s going to be good. I can already tell that’s going to be a hit.

Matt Stine:
Yeah, that’ll be a lot of fun. I’ve learned … Every time I change jobs, I think I learn more than I actually bring to the table as it’s, “Hey, you’re really good at this. We want you to go do this now,” and “I’ve never done that before but I guess I’ll get to learn for a year,” and I’ve learned probably more than I have in quite some time.

Simon Elisha:
That’s fantastic.

Matt Stine:
Because the way we manage products at Pivotal is significantly unique compared to the way a product management is done in the mainstream.

Simon Elisha:
It is, it is way different.

Matt Stine:
Some things good, some things bad, some things just different.

Simon Elisha:
Yeah.

Matt Stine:
That’s been unique, but that product has kept me very close to microservices. Now this whole idea of Cloud Native Application Architectures which microservices are a nice subset of that but bringing all the continuous delivery and devops and cloud. All these disciplines that are saying a lot of the same things but using maybe different words to say those things and saying, “Okay, what is that pattern that you can match across all those different, distinct conversations?”

Let’s give that a name and Cloud Native is the name that we decided to give it. That’s been fun and I wrote the little book on that topic earlier this year as well and that’s been far bigger of a phenomenon than it was ever intended to be.

Simon Elisha:
Run away phenomenon, I think.

Matt Stine:
It really has been amazing to see a little 56 page book show up in places that you just … You walk through the door and, “Oh, look, there’s my book..Multiple copies of it!”

Simon Elisha:
That’s my book, yeah. There’s plenty of them down in Australia as well, so they travel further than you think.

Matt Stine:
Yeah, you can hand out… They make great party gifts.

Simon Elisha:
Christmas is just around the corner.

Matt Stine:
Exactly, exactly.

Simon Elisha:
Awesome, awesome. When we spoke about a year ago, as you say and that was probably the early stages of … If we talked specifically about the microservices architectural trend, it was at the early stages of that. Just to wind back what we spoke about at the time, is a fact the microservices pattern is not an end in and of itself.

The end in and of itself was to be able to deliver more change more quickly, more safely in a software environment. This giving concepts like continuous integration, continuous deployment, test driven development, moving quickly, all these concepts that we talk about a lot.

We spoke about some of those original challenges. We thought that it would be good to just reconnect and talk about what has been learned in the interim period, what we’re seeing customers doing right, what we’re seeing customers doing wrong. We both have a cup of coffee with us so we’re well set and I thought … I was going to lay one out.

I’m going to start with one thing that I saw recently at a customer who was transitioned to microservices and tell a little story. That they were telling me how “Yeah, we’ve got a monolith. We’re starting to develop in microservices. We love it. We deployed an app in the microservice pattern but it went down.” I said, “What do you mean it went down?”

They said, “We only had one instance of that microservice and there was no monitoring on it and there was no HA for it, etc.” I was like, “Aha, you need a platform.” It’s interesting how common it is that people focus on the design pattern of the microservice but not the actual run piece. I guess, you probably have seen a lot of that as well in your travels, Matt, that it’s not enough to build it a particular way, you’ve got to run it a certain way as well.

Matt Stine:
Yeah, I think when we got started having the microservices conversation, there were a few threads that really focused on, “Oh, this is just the latest way that modularity in software is being expressed and it’s just another way that reuse is being expressed.”

If you think about the ways, at least in my world, I’ve been in the Java world most of my career, I’ve dabbled in other things but I always keep coming back to the JVM and the way that we’ve done that in the past, whether it was classes or packages or Java files and we went down the OSGI route a little bit.

Then we had OSGI services that had a service registry and it looked very similar to some of the things that we’re doing now but the one thing that unified all of that was the service that you were calling was running in the same process with you and the way you interact with that was very, very simple. I make a method call and the language run time does the job of dispatching the call from one object to another object and has that code execute.

There’s no sense that, “Oh, that object that I talk to, it may not be there when I decide to talk to it.” That’s a new phenomenon and even the case where I talk to that thing and it’s slow. I have some idea of what’s going on because I have visibility into that process, but now all of a sudden, we’re introducing network boundaries between all of these modules now.

Microservices, they’re just modules. We’re just reusing code but you start to introduce the network and all of a sudden, “Oh, I have a distributed system.” Distributed systems have different characteristics from non-distributed systems, don’t they? There are all sorts of rules, there’s all sorts of other challenges, and there are all sorts of patterns associated with that and so now I have to go learn all of that stuff.

I thought all I was doing was just changing the way my modules were deployed when in fact, I’ve fundamentally changed the system’s architecture and introduced … Maybe I’ve solved my problem of being able to isolate change and go quicker with change, but now I’ve introduced a whole other set of challenges that I didn’t have before.

Simon Elisha:
Yup.

Matt Stine:
Now what do I do with that mess? I don’t know. It’s what a lot of people are running into.

Simon Elisha:
It’s that typical learning process that you go through, it’s you don’t know what you don’t know and then you start to learn more and then you realize how little you don’t know but you start to be more specific about what you need to learn about and it’s interesting.

On the microservices side, a lot of the initial conversations were how big is a microserver? How would you define it? What communication protocol should it use? What does loosely coupled mean? Do you couple with a queue or do you just use … Touch the PS for example. Those questions are the main ones and they forgot the, “Well, these things need to live in the world.”

As you say, we now need to learn about CAP Theorem and the 10 Fallacies of Distributed Systems and all these other really cool and interesting computer science-y things that maybe people have forgotten since their days of study and things are harder to make work. It’s interesting talking about the Cloud Native architectures with customers is one of the things we tend to come back to is that any major software development organization who are building Cloud Native applications have a platform of some sort upon which they build those applications.

None of them are just deploying microservices, quote on quote, “to the wild,” and just expecting them to magically run. They have something in place and I guess that’s where we could probably branch into some of the work you’ve been doing on Spring Cloud Services because that was born out of some of the design patterns of Netflix, wasn’t it?

Matt Stine:
Yeah, absolutely. In fact, it’s not just the design patterns used at Netflix, it’s the actual code in many cases that was used at Netflix. Not strictly across the board but certainly the heart of a lot of what we’re doing is just around code that they ran into these problems and they solved these problems and battle tested the code and ran it at enormous scale and then took the extra step of open sourcing that software.

You can go to Netflix as GitHub repository and you can find all sorts of interesting libraries as well as services that you could deploy to help deal with some of these problems. The thing that I tell people a lot is the delta between cloning the code from Netflix as GitHub repository and having a service that you can run and understand and depend on and start to integrate with your application and just say, “Hey, this thing’s going to solve my problems.”

It’s actually a reasonably large delta. There’s a lot of understanding. There’s a lot of taking this code and figuring it out, it’s not just a matter of deploying your applications anymore. Now you’re deploying some Netflix code that’s separate from your applications and now you’re integrating those things. What we’ve done over the last … I guess, we released our beta five months after we started work and then we released our 1.0 GA version five months after that so roughly, 10 months of engineering work.

Team started out with four engineers, grew to about seven when we got finished and you add up all those hours, that was a lot of development work. What was so hard? Netflix did all the work, right? They wrote all the code.

Simon Elisha:
Yeah, it’s all done. What are you doing? Yeah.

Matt Stine:
Figuring out how to, okay, let’s take that thing, and let’s figure out how we’re going to deploy it, how we’re going to manage the life cycle of it, how we’re going to health check it, how we’re going to scale it, how we’re going to upgrade it when new versions of the software come out, how we’re going to monitor it, how we’re going to control access to it. These are all issues that Netflix has had to solve but they didn’t open source their operational discipline.

You can’t really do that. They didn’t open source the way they handle security. That’s something that’s specific to how they’re running on Amazon so you can’t just take that and drop it on top of Cloud Foundry and say, “Okay, that’ll just work there.” What we had to figure out was what is the best way to take this software and run it on Cloud Foundry. Then integrate it with customer built applications that are going to run side by side with it on Cloud Foundry and make sure that it runs and it keeps running.

Only the people who should have access to it, have access to it and so (A) Developing what those opinions were and then (B) Actualizing those as code that now you go to Pivotal Network and download, adopt Pivotal file and upload it into your operations manager and click a button. Now all of that stuff just works, making that turnkey like that was a lot of work.

What I tell people is, “You have a platform right now, may not be a very good one, but you have one. You’re going to go build a platform, fine. You can do that. There is no option for it to not be a lot of work though.” You’re either going to spend a lot of money on it, in terms of buying software from somebody or you’re going to spend a lot of money on it in terms of paying people to work on that full time and keep it moving forward and keep it running and so forth.

At the end of the day, you’re spending money. How are you going to spend it? What do you want your smartest people working on? Do you want them working on building platforms which we’ve already said, “Hey, you can’t not have one,” or do you want them working on the actual services that are going to differentiate you from your competitor? What’s the thing that you’re going to build that they don’t know they need to build yet or they haven’t even thought of yet?

Because they know they have to have a platform, otherwise they’re not going to survive. You know you have to have a platform. Everybody’s going to have to have one, so the people who say, “Okay, I get that. I’m going to have a platform. It’s going to have these capabilities.” Now what are you going to build on top of it? That’s the real question.

Simon Elisha:
Exactly and that’s the exciting thing and it’s been interesting. I’ve been working with a customer locally in Australia, in fact a government customer called the Digital Transformation Office. Yeah, the name gives away what it is they’re trying to achieve.

Matt Stine:
Right.

Simon Elisha:
They were speaking at one of our Cloud Foundry meet ups just recently and they were talking about how they want as little to do with the infrastructure and the management piece and all that element of investment as possible. They’re just totally, as little as they can get away with and for them PCS fits into that beautifully because it means they’re not managing servers, they’re not managing software.

They’re able to deploy these great patterns of software development and opinionated patterns through the use of things like Spring Cloud Services, etc., and it’s just allowing them to apply what is a set of limited resource. I mean it’s hard to get really good development talent and you want to retain that good development talent and most good development talent, you want to build things that are useful to the outcome of the business they’re working with or for.

People who join the DTO want to make the citizen experience really good. That’s what they’re passionate about. They didn’t join to say, “I want to build a really cool platform.” They’re like, “I want to make it really easy to help someone with a child with special needs get access to funding,” for example and by making that experience a more humanistic experience.

As you say, moving away from this process of always building a platform, Step one, build a platform to be Step one, start delivering value, is a real change for a lot of people but it’s … For some people it’s the mistake you have to make and if others, it’s the mistake they avoid making because they see others making the mistake. I often talk about the best mistakes to learn from are the ones that other people make.

I mean you often remember your own mistakes, we’ve all made them. You remember them well but it’s much cheaper to learn from someone elses mistake. I think going ahead and trying to recreate a platform when it’s already there for you is … It’s just a crazy step to take.

Matt Stine:
Sure, sure.

Simon Elisha:
People do it from time to time, so …

Matt Stine:
Oh, yeah, absolutely.

Simon Elisha:
We point out the folly of what they’re doing and so it’s not a good thing to do.

Matt Stine:
The other that just crossed my mind that I run into now is once we get through the original idea of, “Okay, what are microservices?” and “How are they different or are they even different from traditional service oriented architecture, SOA?” I don’t think they’re actually that different, if you look at principles and not implementations, but besides the distributed systems concerns are what actually constitutes a microservice for me, for my company, for my problems that I’m trying to solve, for my domain?

We have gone back and forth about a lot of different ways to attack that problem and something that I wasn’t thinking about a lot a year ago, that I’m thinking about all of the time now is this relatively old topic now of Domain Driven Design. Eric Evans published a book by that title in 2004. In computer years, we’re talking about ancient literature at this point, right?

Simon Elisha:
That’s right.

Matt Stine:
Who’s still reading computer books that were published in 2004? Not that many people and you get to Chapter 14 of that book and he starts talking about this topic called Strategic Design and he uses this phrase “Bounded Context” and when I first read about it, it didn’t strike me that well. Then when I started reading some of the microservices literature and Martin Fowler starts using the words “Bounded Context.” I’m like, “Okay, that’s interesting.”

Then I really got into where I was working with customers on trying to break down some of these monolithic architectures into services. The thing that we kept running into was if we could just figure out where to put the boundaries. Where the service boundaries should actually be, all of the questions about how big should the microservice be or what things should be services and what things should not and how we actually lay this problem out?

It all falls into the place, if we could just figure out where the walls ought to be, everything else just takes shape. You figure out, “Oh, well, this one should be this big and this one should be this big.” There’s no one size so that all of the ideas about how many lines of code should it be or how long should it take to write or … All of that goes away and this idea of, “Oh, it does one thing and one thing well,” how do you define what one thing is?

Simon Elisha:
Yeah, yeah, but that’s a one thing.

Matt Stine:
Yeah, that’s hard … We had a lot of nice cliches but when you really dig into them, you wonder, “Okay, well, I could define that this way. I could define that that way.” That’s the point is there’s no one answer. Some microservices are actually going to be very small, some of them are going to be quite large when we think of something that we would actually perpend “micro” as a prefix to it.

There’s actually this nascent movement. I’ve seen a couple of people writing articles saying, “You know what, we should abandon microservices and call the Right-Size services.” Actually, I’m very sympathetic to the movement. I think it’s the right idea. At the same time, it doesn’t have the same buzzword quality to it, so it’s probably not going to take off.

Simon Elisha:
No, it’s not as catchy.

Matt Stine:
It’s not going to take off, but it’s right on target because the right size for one of these services is unique to not just the company but the subset of the company that we’re talking about, the problem we’re trying to solve and if we could just figure out where those boundaries need to go.

That’s what Eric Evans talks about when he talks about bounded context and other people in the Domain Driven Design space, when they’re talking about bounded context, they’re talking about where should those boundaries actually be. Getting into the ideas around, okay, how do we talk about the problem? How do we talk about modeling the problem?

We use words. We use language and very early in the book, he talks about this idea of there being a ubiquitous language. What’s a ubiquitous language? It’s a ubiquitous language if everybody’s using the same words and when they use those words, they mean the same things.

If I say customer and, Simon, you say customer, and we’re thinking about a completely different formulation of that idea then we’re probably going to have some miscommunications. We’re probably going to have some conflicts about how we decide to model business logic around customers. If you think of customer exactly the same way that I think of customer, it’s not going to solve all of our problems, but we’re going to have a greater chance of success in translating requirements into design, into code, and so forth.

I really gravitated toward this idea that, oh, it’s very hard to get everybody in the business to use the same words to mean the same things. Because we’re all human beings first of all and so we all look at the world through our own eyes but then we’re all living in different business units. I use the examples of things like product catalogs and inventory and shipping and customer management and so forth. There are things that float around between all those domains.

If you’re thinking about the Netflix domain, something like a movie is going to be very important but we might think about the movie very differently, when I’m talking about the catalog of content that we have versus the inventory of some specific set of media that I’m saying. Of course, Netflix doesn’t really focus on physical media anymore but they do ship it around, right?

Simon Elisha:
Yeah, yeah.

Matt Stine:
Who’s got the DVD right now? That’s a very different formulation of movie than, “Oh, I have this piece of content that has a title and actors and producers and so forth. You find those names, I talk about in my book, this airline that has 17 different definitions for airline reservation and they’re all valuable. They’re all different facets of a gem that you’re looking through.

What do they end up doing? They mash it all into one domain object and it became a bottleneck. It became the thing that everything had to go through and what Evans says in his book is, “You know what, you have 17 different definitions, you probably have 17 different bound in contexts.” I’m leaving a lot of details out …

Simon Elisha:
Yeah.

Matt Stine:
For this conversation but he says, “You know what, embrace that.” You actually have 17 different definitions, you probably have a ubiquitous language that has 17 different dialects. You need to know when you’re crossing from one region of the domain that uses this dialect to another region of the domain that uses this other dialect so you know how to communicate properly and you know how to turn business needs into requirements.

The thing then becomes, okay, what are all those different regions? What are the dialects that they speak? Where are the boundaries between those regions so I know when I’m crossing from one into another, that the language has changed in subtle ways. Then I make sure those boundaries are well defined and I build contracts around them and this is the API, right?

Now when I come to the API, I know, “Oh, here is expressed to me the public semantics of what this dialect of the domain actually looks like.” It gives me the rules of engagement. If I want to engage with this part of the business, these are the rules that I need to follow. Those things become the microservices. They are the things that govern those bounded context and present those rules of engagement through that API.

When I started to think about the world that way, then that tool kit gives me very nice framework that I can walk into any of our customers and say, “Okay, well, I don’t know what your technology stack looks like right now. I don’t know what programming language, what frameworks you’re building things in.” Ultimately, if that’s where our focus is we’re probably going to do a very bad job of figuring out how to go from what you have today to Microservices.

Tell me how does your business language in your domain translate into these key terms and language and dialects and boundaries and so forth. Think about the problem that way and if we can get that part right, then a lot of this other stuff falls into place, right?

Simon Elisha:
Falls into, yeah. Exactly.

Matt Stine:
That’s the framework that I’m using now and it’s been incredibly successful and I can’t take credit for any of that because I’ve borrowed every single one of them from someone else but …

Simon Elisha:
That’s the best way to do things, combining.

Matt Stine:
Using it has been something that’s helped a lot.

Simon Elisha:
One of the things I do see, particularly around that concept of different domains and dialects is that this human trait or behavior or desire to have just one of something. You often hear people talk about as the single source of truth or the ultimate customer record. There’s this innate desire to have just one and it feels like if we have seven different definitions of customer, then something’s wrong.

We’ve got overlap or there’s waste and that’s actually a fallacy. More often than not, when I see customers trying to drive to that single view of the truth, quote on quote, “The truth,” as you say, at first they spend a huge amount of time and introduce a lot of complexity to do that. They end up with everyone being unhappy. It’s essentially not realistically modeling the world they’re up riding in.

If the software model doesn’t map to the actual model of the world, then you’ve got this software dissonance going on there that’s just going to break. I see that, I’d say I see that maybe 30% of the time of people who just have this slavish desire to have one of something and it just doesn’t work out. I could just … It is … You could predict the future almost with alarming accuracy, saying, “Well, this project will be a disaster.”

Because as you say, there is no one view of customer, there is no one view of anything. It’s all about perspective and it’s okay to have overlap. It’s okay to have extra stuff. I think part of the okay to have extra stuff in IT comes from the fact that average cost of IT itself so infrastructure and resourcing, etc., has actually dropped significantly.

It’s not like we’re freaking out because of the cost of a megabyte or storage anymore. If you need to duplicate, you can duplicate or as … Certainly when I started, we were doing everything we could to reduce the size of variables that we’re passing around and what risk doing our disk, etc. Those days are gone now, so we can actually model the context of the world better. You make a very strong point there.

Matt Stine:
I think there’s another interesting thing that’s floating around. We’ve had this idea now for about 16 years or so. Go back that amount of time, there was this book, unassuming book by the simple title of “The Pragmatic Programmer” that was published and that book …

Simon Elisha:
Love that book.

Matt Stine:
Codified a bunch of really powerful, really important ideas that certainly affected the way I’ve done my job since I started and a lot of other people. It was the first real popularization of the term DRY or Don’t Repeat Yourself and you should have one canonical representation of every piece of knowledge in the system. That’s fine. It’s good.

Almost everything that’s said in there makes sense to me and this is actually another talk that I’m working on for next year which is the “Pragmatic Programmer Revisited” and talking about what do we still believe and what’s changed, right?

Simon Elisha:
Mhm.

Matt Stine:
One of the things that I think that has changed is that DRY, some of us have realized, while it’s true in certain context and at certain levels of abstraction, at other layers it can actually be detrimental. It really depends on what am I trying to optimize for right now? Am I trying to optimize for reuse and am I trying to optimize around, okay, if something about this particular topic needs to change, then I only have to change it in one place?

I don’t have to have a checklist of places that I need to go to change that piece of information or am I trying to optimize for keeping a lot of different areas decoupled so that they can evolve independently. When I optimize around those two different … They’re not necessarily a complete dichotomy but there are some differences there. If I start to optimize the things that I’m going to do start to change a little bit.

Sometimes you end up with this tension between, okay, well, if I have one canonical representation of everything, that’s fine. That works very well, except for the fact that now, anything that’s interested in that piece of information, becomes very tightly coupled to that one canonical representation. Yeah, you’re getting a heck of a lot of reuse out of that one module but if that module needs to change, then you potentially have to change everything in your system.

Simon Elisha:
Yeah.

Matt Stine:
When we start building just one of something, what interesting thing keeps happening over and over again is the stewards of that thing get really, really good at saying no. Because they know that if that thing breaks, then the implications are not just that that piece is broken, it’s that everything else in the architecture that needs the services of that piece is broken.

Simon Elisha:
Oh yeah.

Matt Stine:
It goes back to your story that you said at the very beginning of, “Hey, we built this microservice and we loved it and it went down.” We only had one of them and so everything fell over. Well, you can’t have just one of that thing. Whether it’s cardinality or it’s the quality or … I’m struggling to find the right word here …

Simon Elisha:
Yeah.

Matt Stine:
I guess it’s … The nuances associated with a particular … When I say customer and having one and only one customer, what is it that makes that the same? Yeah, they’re talking about a person but what way are we looking at that person right now? What need are we meeting for that person and is that truly something that we can smash into one entity or is it something that’s going to show up in slightly different ways, in many different places? If I tried to couple together, I now take all of those other areas and couple those together as well.

Simon Elisha:
Exactly, and it becomes a false economy and then you also add the human factor in, which is what you were touching on as well, which is that the risk versus reward of making a change. If I know that … Let’s say some department wants a new attribute added to my definition of customer but I know that I’m hooked into 27 other parts of the business with this particular entity and if I change it, it could affect those.

It’s like I’m more likely to say, as you say, say no. It’s the reward for me to attribute just for you is not outweighed by the absolute pain I’ll go through if I mess it up and 27 other groups are affected.

Matt Stine:
Yeah.

Simon Elisha:
You’re effectively stopping change and I guess I wanted to use that as a jumping off point to round back to where we started today, because we talk about microservices as being a means to an end and that end to be deploying software more quickly and more safely and reliably. I’m interested from your perspective what you’re seeing customers being able to achieve in terms of suitable pace of software deployment that works for them?

Not everyone wants to deploy every 11 seconds like they do in Amazon, but I’m interested in what you’ve seen as a example of customers, what they’ve moved to in terms of their deployment frequency these days?

Matt Stine:
I mean it’s certainly … I’ve certainly seen people moving from the scale of months down to weeks and days, depending upon the criticality or the risk associated with the service that’s being deployed. The first challenge that we’ve seen people running into is what do you chunk off. Because even though the boundaries should be drawn here, here, here, and here, it may not be technically feasible for me to draw the boundary right there today, based on the way the design is, how the software’s coupled together.

I might actually need to pull a piece from here and a piece from over there and a piece from down here and that should actually be in a bounded context but pulling all three of those pieces off in one operation is probably very risky. They start out pulling these chunks off and as they’re pulling the chunks off and then they’re combining that with a platform like Cloud Foundry, because …

I’ll give you an example of a customer I went to. They had embraced microservices. They were using Spring Boot but they were deploying to WebSphere. Their operations team was taking that set of eight microservices and they were mashing it into an .ear file and deploying that as a unit to WebSphere. I said, “How long does it take for you to deploy a one line code change into that environment?” Minimum two hours.

Simon Elisha:
Wow.

Matt Stine:
I know the change I need to make. I know where the bug is. I know what the fix is I can go fix it right now. I can check that code in. It’s going to take me less than a minute to get that into production is another two hours.

Simon Elisha:
Wow.

Matt Stine:
We make … Knowing that Spring Boot and Cloud Foundry play so well together I say, “We’ll get this whole thing migrated to Cloud Foundry in a day.”

Simon Elisha:
Yeah.

Matt Stine:
Because I was confident that we could actually do it.

Simon Elisha:
Yeah.

Matt Stine:
We actually did that and it actually was less than a day in terms of hours that we spent and it would have been even shorter had we not made a few mistakes along the way. The interesting thing was was the customer was very glad that we made some of the mistakes that we made, because they saw that, “You know what, I just issued the CF push command 30 times in the last hour.” “I had to put new code into a running environment 30 times in the last hour and it was painless.”

The only pain I was experiencing was my own mistakes that I was making in terms of the code that I was writing but the bottleneck was no longer …

Simon Elisha:
The process …

Matt Stine:
My ability to decode. The bottleneck was back in my brain again where arguably it ought to be, because you’re trying to figure out what are you trying to build or what problems have you created by writing code that’s not correct and the turnaround time, the feedback time. That totally moves the bottleneck. It’s like, okay, no longer is it hard for me to deploy code.

No longer is it hard for me to get code out there and run test against it and verify that this thing is in fact working the way it should. Now it’s just a matter of, okay, (A) writing those automated tests and making sure that they exist and having an automated pipeline that can run through those. There are so many different CI systems out there that you can choose from but taking one and wrapping that up.

Then once you have that, now it’s a matter of, “Oh, how fast can I figure out how to solve the problem that I’m trying to solve and write the code well to actually do it,” because everything else is a button click away.

Simon Elisha:
Yup.

Matt Stine:
Really now, it’s no longer, “Oh, that I have to speed up my ability to deploy things and automate things,” that’s kind of bulletproof now. We know how fast that can go. Now it’s, “Okay, how fast can I get communication from the business of what the problem needs is?” and how I can solve it, solve the problem, and then run through that cycle and give it to a customer and say, “Okay, is this it?”

If it’s not, we iterate and fix it. If it is, then great, we start using it but it’s now how fast can you execute. That’s going to be different for everybody.

Simon Elisha:
Exactly.

Matt Stine:
Not everybody’s going to do input code multiple times per day. In fact, most of our customers probably won’t but the idea of, “Oh, I can now deploy once a week.” I remember years ago before I ever knew … I’m not going to say that. I did know Cloud Foundry existed but it was this little thing that VMware was running in a data center somewhere and I couldn’t use it yet.

I’m a customer of VMware at this point but we had this great, crazy idea that we wanted to deploy code for our business analyst to experiment with every Wednesday. We got to the point where every Wednesday, after we’d all already gone home, something checked out the code and ran through the build and the tests and deployed the code to the business analyst environments and sent us an email that said, “Hey, everything went well,” or if it didn’t go well, it rolled everything back to the last known good.

This was crazy stuff. This was crazy stuff back in 2010, 2011, when we did it, but once we did it, it’s like, “Oh, well, this stuff isn’t hard anymore.” Now it’s just a matter of understanding and we’re working in a place where we have very well accomplished life sciences, PhDs, and MDs who are doing all kinds of complicated experimentation in the lab and we’re building management software for them to manage those experiments.

Just understanding what they needed to get done was an experience in and of itself and then writing the code to do that well, but we removed all the other complexity from the problem. It just became, okay, a bunch of people communicating about solving problems and all the junk that nobody wants to think about, it just worked and we were able to do that for one application.

Now you’ve got software that can do that for many applications, the same way, and remove a lot of these problems.

Simon Elisha:
Exactly.

Matt Stine:
It’s very exciting.

Simon Elisha:
It is. It really comes down to you should be able to deploy as often as you need to. That’s probably the metric.

Matt Stine:
Exactly.

Simon Elisha:
If there’s no magic number, so as often as you need to. If I’m going to deploy a 100 times a time or one time a week or whatever, it should be irrelevant. I should just be able to do what I want and that’s … Then you bring the focus back to where it needs to be.

Matt Stine:
Yup.

Simon Elisha:
Hey, man, I’m noticing that my coffee cup is empty and I’m sure yours is the same. Before we wrap up, it would be I think very remiss of me to not invite you to talk to us about where can we find more information about your baby, Spring Cloud Services and all the cool work that’s being done there? Where do listeners go to?

Matt Stine:
Yeah, sure. The places that we jump off from, we’ve got Pivotal Network, network.pivotal.io and if you hit that link and you scroll down into the Pivotal Cloud Foundry Services section. That’s in alphabetical order so we’re near the bottom of that. You can get to the actual product bits there as well as a link to our documentation site, which is docs.pivotal.io … We’re really creative and Spring Cloud Services is represented there as well.

We have information about how to use all of the different services in our catalog but we’ve coupled that with sample applications that walk you through using the functionality in a controlled setting so you don’t have to go write all your own code to get started. You can use our sample application and make that work and see that everything is doing what it should and use those lessons learned to start working with your own applications.

We’ve tried our best to every time we run into a problem, that a real customer’s having, to take the solution to that problem and bake it down into documentation and have a very capable tech writer on my team who is constantly trying to take problems that we run into and turn them into something that, “Hey, you know what, we’ve got documentation for that.” I’m very proud to say that we have a nice manual out there to help get started.

Between getting the bits and the documentation, you’ve got a pretty decent tutorial on how to walk through and use these services as well as just understand … There’s an overview section with diagrams that says, “Okay, this is the problem this particular service is trying to solve and here’s the pattern that it’s using to solve that problem.”

You have some nice architectural context and there’s an additional resources section under each of those that links to blogs and articles, the original Netflix code if it’s relevant. There are demo videos, screen cast showing how these things work. We’ve tried to make that documentation site a hub for not just, “Hey, here’s how to install it and plug it in,” but “Here’s how to use it and here’s additional resources as well.”

If you exhaust all of that information, you’ve been working very hard.

Simon Elisha:
We’ve done well. It is an awesome resource. I think even just the concepts that it explains are really relevant, whether you’re using the platform or not because it’s stuff that’s universally applicable. It’s a great resource.

Hey, Matt, thank you so much for joining me today on the podcast and I’m sure it’s been interesting for listeners to get some perspective. We’ll have to have you on again real soon.

Matt Stine:
Yeah, you’re welcome. Maybe we should not wait a year next time.

Simon Elisha:
Deal. Good call. Thanks very much, Matt.

Matt Stine:
Thank you.

Simon Elisha:
Thanks, everyone for listening. Again, if you have any feedback, we’d love to hear from you, podcast@pivotal.io and until next time, keep on building.

Announcer:
Thanks for listening to the Pivotal Perspectives Podcast with Simon Elisha. We trust you’ve enjoyed it and ask that you share it with other people who may also be interested. Now we’d love to hear your feedback, so please send any comments or suggestions to podcast@pivotal.io. We look forward to having you join us next time on the Pivotal Perspectives Podcast.

About the Author

Simon Elisha is CTO & Senior Manager of Field Engineering for Australia & New Zealand at Pivotal. With over 24 years industry experience in everything from Mainframes to the latest Cloud architectures - Simon brings a refreshing and insightful view of the business value of IT. Passionate about technology, he is a pragmatist who looks for the best solution to the task at hand. He has held roles at EDS, PricewaterhouseCoopers, VERITAS Software, Hitachi Data Systems, Cisco Systems and Amazon Web Services.

More Content by Simon Elisha
Previous
Why You’ll Need An Open Source Playbook For 2016
Why You’ll Need An Open Source Playbook For 2016

Open source software, such as the Apache HadoopⓇ standard within the Big Data realm, has become the default...

Next
Show Me The Customers: A Former Analyst’s View Of The Big Data Space
Show Me The Customers: A Former Analyst’s View Of The Big Data Space

After his first month at Pivotal, former Wikibon analyst Jeff Kelly starts his contributions to the Pivotal...

×

Subscribe to our Newsletter

Thank you!
Error - something went wrong!