Data, Why Did It Have To Be Data?

November 18, 2015 Coté

sfeatured-podcastIn this episode, Coté once again chats with Andrew Clay Shafer about the sundry challenges of transforming to a Cloud Native enterprise. We start talking about the changing focus we’re seeing among Pivotal customers: moving up the stack from infrastructure to the application layers. Then we discuss the difficulties of handling the data layer, and wrap-up with some change management tactics for getting the “rank and file” inspired and bought into the Cloud Native lifestyle.

PLAY EPISODE

SHOW NOTES

TRANSCRIPT

Coté:
Well, hello again Andrew, it’s been a little while since we’ve talked. We’ve got such a large team now, that I have to systematically go through and talk with our teammates, and put you on the back burner to talk with.

Andrew Clay Shafer:
Well, I’m not hard to find.

Coté:
(laughs)

Andrew Clay Shafer:
We do have quite a crew now.

Coté:
I know, how big is the team we have now?

Andrew Clay Shafer:
We’re ten strong.

Coté:
Wow, ten people. We are writing a lot in that slack channel. I keep thinking I need to set Josh Long up with his own … I always jokingly call it the Josh Long Open Mic Channel in Slack, where he can just come in and he just has this wonderful stream of consciousness things and I think I need to finally do that. That would be wonderful.

Andrew Clay Shafer:
I’m not sure Josh writes more than anyone else though, he just writes it all at once.

Coté:
He batches it up, so it has this … It is sort like every now and then there is this sort of drive-by communication, which makes it seem like a large volume.

Andrew Clay Shafer:
Where the most of the rest of us are streaming, he’s got the batch paradigm.

Coté:
We smooth it out. Just like delivering everyday, we smooth out the risk, instead of like these big, giant curves of things.

I bring that up because that is a thing I wanted to go over, is very … I was doing some background reading for our … We have a new release of Pivotal Cloud Foundry® (PCF) coming out soon and I was looking at what we had the last time I did a bunch of work around this and I would say the nature of what we do, and especially after talking with customers a lot more since starting back in January, has modified a lot.

There is still a ton of operational and Cloud things that we do, but a lot of what is going on now is going up the stack as well and addressing a lot of the application development and architectural concerns. The ‘What are you actually going to do with that Cloud’ type of stuff.

I think with the team that we have, which is sort of like the advocate team. Some people might say evangelist, but the people who go out there and try to explain what is going on and also to discover and help out. A lot of it is really … A lot of people on our team are application centric and I think that reflects what, at least in the customers and prospects that I go to visit, the people who are using PCF, a lot of what they are interested in.

They definitely want the operational stuff, but they are now pushing it towards ‘How do we get into microservices and managing our application development in a new way?’ Just to wrap up like … I am starting to look at it as like the evolution of, to use the proper term, the JEE market, as we record JavaOne is going on now and there is a lot of, obviously from that community, figuring out what their mainstream future looks like and I feel like we have a pretty good position of the companies that we talk with.

Many of them, they don’t all work in Java but a lot of them do, and they are looking at what we have been espousing in the Cloud Foundry world as the way we should architect and develop our applications, which I think is pretty interesting sorting that out.

Andrew Clay Shafer:
Absolutely, and I would say, and probably as partly what I have done before, and what people know me for, I still get pulled in to the ops-centric conversations and we definitely still have those, so I wouldn’t say so much that we have shifted everything to be apps-centric, although there has been some of that. It is like we have included that as more …

Coté:
Exactly, exactly.

Andrew Clay Shafer:
That focus looking at and connecting the dots from the bottom to the top, incorporating Spring. That is part of this new release, Spring Cloud Services, they give people access to a bunch of convenience with things like the Netflix OpenSource, you can run in production the same kind of stuff that they have been running.

I don’t know so much that we have shifted, but we have added and expanded that conversation to include the apps, whereas before, as you pointed out, it was much more focused on the infrastructure and the platform capabilities.

Coté:
Yeah, and I think that is exactly the right framing and I think one of the most recent visits I had out in the field with people represents that. Where there is … And this is what seems to be happening in the industry in the AppDev and Cloud Space, is people like to start at the bottom.

They like to start out with the computer, the silicon if you will. Then build up of how they manage the infrastructure, how they do all the operation stuff and how it gets built out. Then that kind of derives the style of application development that you will do. The chattering class of the industry spends a lot of time at that orchestration, the middle of the stack if you will.

When I go out and talk with people, they are very interested in what is going on right below the application layer and they want to make sure that is covered and handled as well. When you close out that conversation with them, and you explain how ‘Here is our vision of how highly automated infrastructure works and how we govern and coordinate the way that processes and applications run and they coordinate together’.

Then it is like it opens up the next door, which is like ‘Alright, now we need to write some applications and design them.’ I think it is those two conversations together that give you that fuller view and what I have noticed, especially over the last six months is that most of the people I go out and talk with, they have to go through that whole conversation and once you hit on the applications stuff, there is this whole other group of people that you talk with.

The more of the enterprise architects and they are much more closer to the end users and the way they are sorting through how to use things like Spring Cloud and how to come up with their microservices is fascinating. It is fun to see them sorting out the new architectures they have to put up with.

We were talking before, we were recording how a lot of the … A lot of the style of the architecture is very similar to how you connect together a bunch of processors on a Linux or Unix command line.

Andrew Clay Shafer:
Except now it is distributed. Now your schedulers are across this fabric of resources instead of on this single machine.

Coté:
Right, and that is where you have to have this marrying of operations and application together, right? There was this time that, back when both of us did Java development, where there was this fascination with how distributed architectures work and how distributed applications worked and you kind needed to know all that stuff and then it seem to wear away slightly.

At least at the architecture layer, but now that we are back to doing, or thinking about, and being cognizant of doing distributed application architectures, now you do think about all that stuff.

Andrew Clay Shafer:
I think there is a general trend to reinvent CORBA about every …

Coté:
(laughs) Exactly.

Andrew Clay Shafer:
Every so often.

Coté:
That is why it is staked into the JDK!

Andrew Clay Shafer:
I also think that there is an aspect of Scale, both scale and velocity, that is different now than we saw in the past.

Coté:
Yeah.

Andrew Clay Shafer:
I think that what happened in … You just kind of alluded to it. There are sort of these basic, primitive, clustering approaches that were kind of baked into the J2EE app servers, but they’re not really built to deal with the scale of the architectures that we are seeing emerge right now.

Coté:
Right.

Andrew Clay Shafer:
A lot of that just comes down to the hard problems of managing state, which for whatever reason, it seems like a lot of people refuse to think clearly about.

Coté:
Yeah. I think that is the hard problem. (laughs) And making sure that you write your applications to properly deal with state. Or ignore it. That is the other trick, figuring out when to ignore it, but that is where the annoyances come in.

Andrew Clay Shafer:
I think the trick is, and I mean this as seriously as a I can possible be and if you have ever met me, that’s really serious, but the trick is pushing that place where you handle state into the place where you know that you can do it deliberately instead of … I think there is a tendency for people to just smear state across a bunch of stuff and they are like ‘Why is it so hard to manage state?’

Coté:
Yeah.

Andrew Clay Shafer:
Instead of like ‘Okay, let’s do everything we can as stateless as possible and then where we need to deal with state, we make that very deliberate and then we can do things in a … This kind of goes back to my mental model that I have been trying to get people to understand around promises and contracts and the rest of the stuff.

If I have to have state everywhere and manage it in different ways everywhere, then I have a lot harder time keeping my promises, than if I have deliberately set up the stateless processes in a certain way and then the stateful processes in another way, then I can kind of manage those in a sensible way that makes sense and I can reason about it.

Reason about both how it will perform, how it will fail, how I can recover, all of these other things that I want to do to manage the full lifecycle.

Coté:
Yeah.

When it comes to the database, that is a recurring conversation that I found myself and other people having, whether or not I am talking with people, is … There must some name to this effect, but if you centralize all of your storage to one place, as most people do into a traditional, big database, there is a certain cut-point where because everything is in that one place, it introduces a huge amount of complexity, that you end up spending a lot of time with.

Versus always trying to have … Reverting back to that contract state, where you have state is really … You keep it as simple as possible, like the APIs do it simple, and you don’t necessarily jam it all into one database where you have to start worrying about ontologies and taxonomies and how you modify things from time to time.

I obviously haven’t figured out what the answer to this is, but it is interesting talking to people who are very obsessed with this schema and how you update schemas, and how you do table upgrades and all of this stuff. Those discussions don’t necessarily come up as much in a microservices world where state is treated differently than a big, honking relational database that you are always tracking with.

There is always this general thing that I have noticed, where the concerns you had, that you used to have … You are using different technologies, so you don’t need to worry about those things too much. Like spending months governing the perfect ontology of what your data model is.

Andrew Clay Shafer:
Yeah, that is wrong.

Coté:
(laughs) Right, right.

Andrew Clay Shafer:
The first day.

Coté:
Yeah, well that’s always been an exciting issue. (laughs)

Andrew Clay Shafer:
I think pretty much every time I talked, this predates anything to do with Cloud Foundry, that the conversation pretty quickly got to ‘How do you do database migrations?’

Coté:
Yeah.

Andrew Clay Shafer:
It is like ‘Well, these are technologies that weren’t actually designed to be operated. They weren’t actually designed to be … ‘ This is something that I got all of our team … I don’t know if you have ever watched the Joe Armstrong on the ‘Six Laws of Reliability’?

Coté:
Right.

Andrew Clay Shafer:
One of the Six Laws of Reliability is that if you want a system that never stops, then you, by definition, need to be able to do live upgrades. How many database engines have baked into them, and there are starting to be some, this notion of a live, online upgrade?

Coté:
Yeah.

That is particularly hard in a database, because you have this single point of running. (laughs) Not to call it a failure, but as you were saying, like the database was not written to have live upgrades so much. It is not written to operate that way, which bubbles up this annoying constraint.

Andrew Clay Shafer:
What year was the SQL Standard published?

Coté:
Yeah. Isn’t the most recent one like ’92 or something? It is probably more recent, but that is what I remember learning.

Mmm, good old SQL.

Andrew Clay Shafer:
These things go back decades and it was a different world, with different needs and that is why you have seen all the large, kind of web-centric, cloud needed companies move to other types of approaches, and this is a buzzword of the yesterday, but no SQL, I suppose it still has some conversations, but the methods that people are using to run Cloud Native, large scale, highly available, rapidly changing applications, are kind of different that relational model.

Even when you have those relational databases, when you start doing things like sharding, and then they have the read and writes and you have separated, we don’t like using this language but it is the one everyone uses, Masters and slaves.

You basically went to a conventionally consistent, kind of separated model anyway, you just didn’t take full advantage of the opportunity to separate it all the way, because you are still basing on that older technology.

Coté:
While we are on the data topic, as it were.

That’s right. (laughs) Here is something that I haven’t sorted out yet, but I have noticed. This is a question that I have had in my mind.

One the one hand, you want to minimize variance, as you were saying, and have some common ways of handling data. Then if you look at orthodox microservices speak, like every single service that you write, or microservice I guess, can make decisions about using its own data store.

So far, I haven’t reconciled in my mind, those two things seem somewhat at odds. The questions is when you look at Cloud Native architectures, how many different types of data stores are there really out there. Do people end up choosing just a handful or a couple, or do they just choose what really makes sense for the service that they are using?

I think this is a perfect kind of thing for the two of us to go over, in the sense that you can approach it very well form the operations side, and I can approach it nicely from the ignorant developer who would … I am like the person who would end up using MongoDB, or whatever, because it looks awesome.

Andrew Clay Shafer:
It is that dopamine drop, they get it right in the first …

Coté:
Exactly, especially when microservices are connected, so with PCF, it is like we have all sorts of supported data services, that you can use self service, and the way that you end up managing them can be kind of normalized.

It does raise the question of how many different data stores do you actually want to end up using?

Andrew Clay Shafer:
I was once a naïve developer, I probably went through this arc and I think if you look across the different types of projects and people that do these things, I would, in my project if I was running something that was a small team, I would try to minimize the variation of the different databases.

I don’t want to have … There is an operational overhead, there is a cost of ownership to adding complexity. There is a bunch of things that I think the right answer for is ‘You should just use Postgres. What ever comes out of your mouth, Postgres. That is the deal.

Or you could make it work with MySQL or something like that too, but as you start to get into a more specialized understanding of what your needs are, what your writes and your reads and a bunch of these other things, then it starts to say ‘This is probably a good fit for Cassandra. Or this is probably a good fit for some of these other things like Riak’

Having the ability to make those decisions deliberately, like with full understanding of what the cost and benefits are, is something that … There are communities that have these kinds of discussions. If you seen some of the stuff, conversations that have gone on in places like Velocity and DevOps Days and Recon is coming up as interesting thing as well.

There is that body of knowledge, but the spray and pray, like ‘let’s put every database into the system’, I think that ends up having more operational costs than benefit.

Coté:
Yeah, sounds like there is a lot of praying that happens as a result.

Andrew Clay Shafer:
I think, honestly, and this is something that I think all of us have to some degree, it is fun to build things with new toys, and then those are also resume generating events, so if you read hacker news, or scan what people are talking about on Twitter, and you hear someone did something, then you kind of want to see what that is about. There is also, and there are people that talk about this, explicitly.

Etsy is heralded as one of the more advanced, in terms of devops and automation and deployment and continuous delivery and all that kind of stuff. They also have this great culture. They blog about The Craft and Blameless Post Mortems.

They also blog about their deliberate choice of boring technology. They are not trying to drive everything with the newest, shiniest toy. They approach things with the mindset of ‘I know how this will perform, I know how this will fail, and if you look at their TextDoc, it is vanilla, PHP, running on a relational database.

Coté:
They are just technologies you can trust.

Andrew Clay Shafer:
Right.

That should that should not be discounted when you are evaluating a lot of the new, shiny toys that you don’t really understand what the … My strategy, like as a technologist, I don’t actually like living on the bleeding edge of technology. I like knowing that it is there. I like reading about it, maybe even dabbling with it, but when it comes to putting things into production, I kind of want to … If you think about the model of the chasm, like I want to be on the front lip of the chasm, basically.

That is where I think … You want to have reconnaissance to the early adopters, and the rest of it, but there is a reason it is called bleeding edge, and a lot of those technologies are not viable. They are not going to be there.

Do you want that to be your blood, or someone else’s?

Coté:
Yeah, that makes sense.

Andrew Clay Shafer:
Plus … I don’t know. I think there is a fascination with technology and then there is the pragmatism of trying to get things done and I think that is a pendulum that swings. As you get new paradigms and new technologies, it can open up different opportunities to be productive, but you can also spend a lot of time … Waste a lot of time with technology that is not really ready enough.

I don’t want to name any projects, but I have some fairly public rants about some of these types of things.

Coté:
So it seems like … There is a general principle to extract there is like, ‘So you should probably choose newly mature parts of your stack.’ Things that are … You don’t want them to be too old and slow moving and crufty.

Mature is a wrong word, because that connotes years, but it is more like you want some assured stability of what you have, especially in the data layer, which might end up reducing the amount of data storage you can use.

First of all, can you just do it with Postgres? If so, you should probably just use that. Then if you requires something above and beyond that, then it is good to have something like both operational knowledge of like ‘Can we operate this and is it reliable’, and also the developer dopamine driven knowledge of is this really fast and easy to use, and have more of a balanced evaluation of using those things.

Which, getting back to my original question, I think would very quickly cull out way too many … I shouldn’t say way too many. Cull out having a bunch of different data stores in your architecture. That will whittle down to just a few things pretty quickly.

Andrew Clay Shafer:
When it whittles down to a few classes of things, as you understand the overhead of renting those, the cost, there is a time when there was a new database that came out, not going to name any names but if you know this then you probably have been paying attention, and they published a bunch of benchmarks and it is like ‘Oh, we are faster than these other databases.’ Okay.

Then you go look at what they are doing and they were taking writes, but never putting them on disks.

Coté:
(laughs.) Right.

Andrew Clay Shafer:
So that was a trick that says ‘you wrote something to this and it wasn’t actually written.’ It was faster, but it wasn’t actually doing the same work, so it was only an illusion … It was an illusion of speed and the trade off was you never actually wrote your data, so a bunch of people implemented this database and then they ended up in situations where they lost data, or they couldn’t recover from certain types of failure. That is the type of operational maturity I am talking about, what is the trade off?

Maybe there are situations where it makes sense to have that be the thing you are optimizing for. I don’t care about this, I can deal with that failure mode and that is fine and I will take that trade off, but basically you should realize that is ephemeral data that is not going to be written to disk, or it is not going to be written to disk when you thought it was. That realization, that maturity, being able to analyze those trade offs, is what I consider that kind of system architecture.

I am going on a slight rant for a second. There is this notion of architecture that is getting discussed right now, that is sort of ivory tower focused on code and we are going to talk about the code and it is like we have these separations of concerns and solid and all of this stuff. That is not bad, but there is this missing discussion about system architecture.

That there are a few people and you sort of see this slightly discussed, although it is not explicitly as I’d like at places like Velocity and Surge and maybe some DevOps Days, but there is this gap between the architecture that people talk about with respect to code, and then like the actual system architecture.

I feel like there is a body of knowledge and there are practitioners that have kind of internalized this stuff, because there is not great resources and there is not great conversations, or communities, where people are able to kind of … You basically have to learn it the hard way right now and that sucks.

When I go into places and we have conversations with customers and we see some of the stuff that is going on in the field, I really wish there was these resources where you could say ‘Okay, here is how you should think about these problems. If you want to move fast, if you want to move at scale, here is a bunch of properties around systems and architectures’, and I think some of that falls out when you start framing things in terms of promises and contracts, but there is just like this hands on, kind of knee deep in the mud, chest deep in the mud kind of experience and conversations with people who have been through that. It is really lacking and I wish there was a fast way to give people that knowledge, but I haven’t figured out how to do it.

Coté:
We talked about this before, but it feels, like across the industry, it is sort of like across the vendors and the people who are developing these technologies, at the moment, collectively, we are not really interested in having a known de facto standard.

Everyone across stacks talks about how they accomplish a common systems architecture differently. They all have different words for it and the don’t necessarily unify it together so much. As a result, you don’t have a common … I don’t know if we are even at the state where we have a common concept like a three tier architecture.

Andrew Clay Shafer:
(laughs)

Coté:
Or one of the more recent ones was the LAMP stack, where it was like ‘This is the general pattern that you are going to follow, and what P means might be different between all sorts of things. It might actually be an R instead of a P or whatever. It is basically the same stack, which implies the same architecture, but at the moment there is so much fragmentation out there with all of the, I don’t know, various infrastructure stuff, that is almost like we are saying the same thing, but using different languages. We at the Cloud Foundry Community, it all kind of speaks the same, but there is other clusters out there who are speaking differently.

As a result, when you go out there and talk with people, you almost have to start from scratch and triangulate and figure out the common terms and words that all map to that sort of bucket of common systems knowledge, which is varying degrees of helpful depending on what you are interested in and are trying to accomplish.

Andrew Clay Shafer:
I think that is actually great and is exciting. It is the process where you go from innovation to kind of productization, there is a … There tends to be a Cambrian explosion of approaches and then I expect that to … I don’t want to say that will clash, but you will emerge with the standards based on de facto, or … I am not always the biggest fan of standards of bodies, committee driven standards.

As those things emerge and the utility of those things emerge, then it doesn’t make sense for everyone to reinvent everything from first principles all the time, but we are kind of in that phase where we are transitioning to that new architecture and everyone can kind of feel it in their bones and we have picked up the mantle of Cloud Native and that is the way we are framing it, and we are seeing more and more of the industry adopt that same kind of verbiages. They are all kind of saying the same kind of thing, although they all might have slightly different approaches.

Sometimes it just comes down to … Some of it comes down to politics and … I say this all the time, basically, technology is driven by fashion and tribalism, muchmore than it is driven by logic and reason and we are just watching that play out in our space.

Coté:
Yeah. I think if have been seeing that trajectory, especially since I have been at Pivotal, since the beginning of this year, but even back when I was an analyst there is a … It is almost like a, I wouldn’t say drunken, but a mildly buzzed meander down the street to coalesce to the same stack.

So you see a … There are cheesy ways you can track it. You can sort of see the weekly infographic that comes out, or kind a see the evolution where like we are in conference season now, so you can see the evolution of the corporate slides that describe the stack and they are all starting to look the same and have similar layers and we will just be in that kind of battle to have the exact words of what they apply to.

Andrew Clay Shafer:
I think the thing that is clear, is that there is a new way to do things. There is going to be a transition from whatever … We already kind of touched on the sort of app server that came out and tried to solve problems, but that technology hasn’t really evolved for the last ten years.

Coté:
Exactly.

Andrew Clay Shafer:
So the enterprise people, the startup people, they are all kind of finding this new way to do things and that, whatever that next thing is, we are basically inventing it together everyday.

Coté:
Then as the last topic, let me go to whole other part of this stack, so to speak, and just get your take on something I have been noticing recently.

I have gotten to speak at several internal tech summits at companies recently, and it is really encouraging, because the high level management is basically saying to the staff, we will just put it that way, like ‘You should go out and do new stuff’ right? Like we want you to look for new ways of doing things and be creative and really explore new ways of doing things.

I have seen a couple of examples firsthand, where, I guess the staff kind of doesn’t believe them and they are still almost shell shocked from a command and control structure of doing things. I have my own things that I tell like the management class and the staff class of how to get over that divide.

I am curious how you sort of talk people through that, in the sense of ‘We actually, genuinely want you to go out’, and this is the example that comes out is, ‘We have picked a project that you can basically learn from that as you can kind of fail and we in the management level would really like you tell us the failures and the learnings that you have. They are really working on building up that trust between these two levels at the moment.

What I have noticed recently is that the staff level layers … It takes a big leap of faith for them to do that. (laughs) It is almost like I am always theorizing and curious about how the managers, if you will, can start to construct to these trust lessons that have sort of like metaphoric falling back and trusting them.

It is something that has been popping up more and more that I think is an interesting thing we should be advising people on more.

Andrew Clay Shafer:
Yeah, I think this a fascinating thing to watch and something that the, I’ll just keep saying this word over and over, the Cloud Natives realized awhile ago, but we are seeing more and more of the enterprises start to realize this, which is that software, technology, these things are a competitive advantage, not a cost center. Not a nice to have and then the other thing that is driving this is when you really understand what it takes to make great software, you realize it is not a science, it is closer to art. It is a creative act.

The types of work that you manage with whatever, essentially the industrial processes that kind of came from, literally, the Industrial Revolution, if you try to manage software with that kind of command and control approach, then you don’t tend to get the best outcomes.

That transition … I think it is hard for both sides. It is not just the “Underlings” that are struggling with that trust, it is also the manager, it is also the organizations where … I think is one of the things that is interesting. If you look across the majority of the Cloud Native companies, or the big tech giants. They are kind of the newly emerged tech elite, are by and large, led by technologists at the highest level of their executives.

Coté:
Right.

Andrew Clay Shafer:
Where for the enterprise, even the CIOs of these companies, are not terribly technical. That sort of puts you at a significant disadvantage when as someone who is trying to evaluate the technology, trying to evaluate the technical direction of your company, of your whole strategy, you are kind of beholden to the consultants, you are kind of beholden to whoever has the most confident sound in their voice instead of being able to reason about the technology yourself and that puts you at a disadvantage.

One of the things … I just read an article in the Financial Times saying that only 6% of the banks have technical people in their executive team.

Coté:
Alright. Just to footnote really quickly, hopefully not to make you lose your train of thought. That is interesting because I have had this conversation with several people who … They kind of see … They see a generational shift in managers who are, not even Cloud Natives, but computer natives, and who have much different expectations about what technology should be doing and what is capable of, which hopefully will raise that 6% up, but as basically as software is more in the fabric of our lives to see all that. Hopefully that will help out on that point.

Andrew Clay Shafer:
Yeah, I think there is a bunch of interesting ways to frame that, but not to belabor the war metaphor too much, but if you have generals and officers who never felt the mud, who don’t know what it is like to shoot a weapon, or be in actual war, then it is much … The types of decisions that they make and the way that the preform is very different than if you have some of that DNA in the leadership.

Coté:
Right. Have you, whether first hand or second hand, encountered ways of building trust between those two groups, like they are actually shifting things over, or is it largely contextual? How does that pan out?

Andrew Clay Shafer:
I have a few tricks. I think that a lot of this comes down to empathy and recognizing the human aspect of it and there is one of the exercises that I made up in … There was a workshop I was sort of thrown into, this is way before Pivotal days, and someone had … Basically, they tried to do an agile transformation and the developers were loving it and then there was kind of total organ rejection from the ops team.

Then someone said ‘Well, let’s throw Andrew into that and see what he can do’. So on short notice and with very little preparation, I was put on a plane and flown to try to help do kind of therapy for these teams and on the spot after I got in there, I saw what was going on and talked to them and we are all spending two day together, I made up this exercise where I made them interview each other and then what they do is each … I tried to pair them up with whoever they thought was the farthest away from themselves in the organization and we spent an hour with those two having a conversation and then each one of them had to write a press release.

They are all technical managers, or technologists, at various levels of the infrastructure and applications and they had to write a press release for how that other person, that they just spent time with, adds value to the company. Feedback from, basically, everyone that that was the most amazing thing for them, because for the most part, those were all like nameless, faceless functions.

They knew the person existed, but they didn’t really understand what they did everyday, they didn’t understand why they did it, and so, to me, trust is about patterns of behavior and if your tribal notions don’t extend to this other person’s perspective, their viewpoint, obviously if you are in someone’s cube and you see a picture of their kids on the wall like ‘That’s a person?’

But if it just someone you interact with through tickets and they are annoying because they are not doing the thing that you want immediately, even though they are practically on fire themselves, then you don’t have that same kind of empathy and empathy to me is like the basis for a bunch of these things getting solved with respect to trust and understanding.

It is the same thing where as a technologist who struggled with technology, who struggled with delivery, who struggled with innovation, if you are leading a team that is going to go through that whole cycle together, then that is a very different approach than if you are just like ‘Oh, I need to have these features by this date so I can make this other thing happen.’

You would like those things to line up, but it doesn’t actually get you better software to just crack the whip all the time.

Coté:
I think this falls in the category of … I remember that conversation you had with Matt Curry awhile back. There was a delightful part I always reference where no one seems to believe the advice coming out of these unicorn companies. That they actually have two pizza teams and so forth and so one. They are always like ‘What are you really doing, because that sounds like a bunch of hokum’ and it is … We have this layer in our stack of understanding what the stack is, called the Cloud … The Empowered Culture, basically, which enables all of that, as you were saying, the basis of it and I have seen this over my career, and definitely recently as once you start getting people trusting each other, which sounds like one of those hokum things like ‘Surely that is not how you make things operate form in an adult world’. Once you actually get people trusting each there, then everything else is possible and more falls into place.

It does seem like you have to take a leap of faith, if you will, that this is something that you need to work on, but then whatever time you spend actually getting people to treat each other as people (laughs) and just be normal and human, that tends to pay off when it comes to actually … Whether the management people and you want your staff to execute along these new ideas of exploring and being creative.

Or in the other direction like if you are coming from the bottom, so to speak, and you want management to understand a more agile sort of learning based approach to doing things, you have to get management to trust you as well, so it starts to make sense to actually start to know the people so that they believe what they are saying, to build up empathy.

Andrew Clay Shafer:
Absolutely. Yeah, the trust has to go in both directions for sure, and I think that my experience seems to indicate that you got to get these self-reinforcing upward or downward spirals and as you start to have results and as you start to trust and become a high performing team, you never want to go back. That just becomes the thing you want to keep getting better and better at.

Where if you are in that cost center mindset, the scarcity mindset, then that downward spiral actually drives you deeper and deeper into dysfunction.

Coté:
Indeed.

I think that is good place to wrap up. We have covered a lot of, in an exciting, scattered kind of way, a lot of interesting new developments around here.

Do you have anything else to say before we end it?

Andrew Clay Shafer:
The one thing that we had aspired to talk about, that I think … Maybe we don’t explore this fully today, but we come back and it might even be fun to do this with a couple different personalities at the same time, is this transition, this separation, that we are seeing.

We kind of started hinting about it when we were talking about this proliferation of solutions, but what I am seeing is a trend towards much more application-centric approaches. Application-centric user experience with a platform that we are focused on versus the, what it looks like, very infrastructure-centric approaches that other projects seem to be taking.

Coté:
Yeah. That would be a good panel conversation to have, maybe. I think that is what I end up seeing is most of the conversations that I get into nowadays, thankfully are ‘How do I architect these things out and what is the implication of using a microservices based way for the way I evolve my services … For the way I evolve my application?’

The bridge I always try to go back to, especially with the large organizations I talk to, is ‘Remember all that SOA stuff? There were a lot of interesting, good ideas in there’, and trying to sort out how we can actually make it work well.

Andrew Clay Shafer:
Absolutely.

Coté:
I have actually did it in a lot of weird conversations recently, trying to diagnose what went wrong with SOA.

Andrew Clay Shafer:
What went wrong with SOA. (laughs)

Coté:
I think a lot of it … My theory so far is that it was the original goals were pretty much the goals that we have in the application architecture conversations nowadays. ‘Let’s make a bunch of services that represent various types of processes in our business’.

In the retail world you have inventory. You need to send the inventory out to various distributions centers that show up in stores. You need to do an accounting of who bought what. All this stuff breaks apart into a bunch of little services and types of data.

We want a common way of representing those services, so that we can, very rapidly, write applications that do something with it, like if I want to compete out in the crazy unicorn world and have an app that allows someone to buy something in my store and someone is going to go into the store and pull that item from the shelves and deliver it, there is a bunch of software that you need to write to make that operate effectively, rather than faxing things around or something.

Andrew Clay Shafer:
I think what I am talking about here is slightly different framing, which is that everyone is talking about this new paradigm, everyone is talking about these new architectures, but the way that you interact with them, are you coming from the bottom and building them up from the primitives of the infrastructure, or are you abstracting them from the top and saying ‘These things should exist’ declaratively and then letting the automation, the application, which is the automation, make those things happen?

Which persona, if you will, is that experience optimized for?

Coté:
Right. That makes sense.

Andrew Clay Shafer:
Anyway, that can be a whole hour.

Coté:
That’s right.

Andrew Clay Shafer:
Easily.

Coté:
Yes. What went wrong with SOA?

Andrew Clay Shafer:
I know … I mean

Coté:
Where is the body buried?

Andrew Clay Shafer:
It is actually … It was … It aspired to be a service thing, but then it was implemented as a monolith.

Coté:
Right. That is the avenue that I was getting to, like laying out that lengthy example there.

You want write out this new application there that needs to use all these services and you end up spending all your time specifying what your data looks like. You spend all this time about the interchange and the offerability and very little on the original goals.

That seems like that distraction that happened, ended up focusing on the wrong thing, versus something closer, or something that feels more like what you were saying. ‘Well, eventually all these services need to coalesce and run. They need to do something, not just perfectly exchange data’

Andrew Clay Shafer:
I think basically what you are saying is you start out with this great idea and then, as always, it was re-implementing CORBA.

Coté:
Exactly. (laughs)

Andrew Clay Shafer:
That’s what happened.

Coté:
We didn’t like our IDL files, so now we have soap files.

Andrew Clay Shafer:
Exactly.

Coté:
Perfect transition. Well, on that delightful XSD note, no conversation is complete without a reference to XML, I guess.

This has been Pivotal Conversations. You can always find the show notes and what we have at pivotal.io/podcasts or podcast and we will see everyone next time.

Bye-bye.

Andrew Clay Shafer:
Until next time.

About the Author

Biography

More Content by Coté
Previous
The New Flo for Spring XD
The New Flo for Spring XD

Flo for Spring XD is an incredibly powerful tool with a graphical canvas and DSL access. This first product...

Next
Try Out Pivotal Greenplum With A Sandbox Virtual Machine
Try Out Pivotal Greenplum With A Sandbox Virtual Machine

I recently attended PGconf in Vienna, Austria, where we announced the open-sourcing of Pivotal Greenplum, w...

×

Subscribe to our Newsletter

Thank you!
Error - something went wrong!