My name is Preben Thorø. I'm sitting here at GOTO Copenhagen, and I managed to bring together
Nicki Watt and Ken Ken Mugrage. We're here to talk a little bit about software improvement.
Before we kick-off, I would just ask the two of you if you could just quickly introduce yourself.
Sure. So my name is Nicki Watt. I'm the CTO at a company called OpenCredo.
We help companies to adapt and adopt emerging technologies to solve their business problem,
working quite a bit in a distributed system space. That's me.
I'm Ken Mugrage. I'm a principal technologist with a company called ThoughtWorks
mostly working in continuous delivery and stuff for about the past decade.
So continuous delivery, I heard about that, first time, 15 years ago. I have a feeling it's
taking off now and not until now. Why is that? A lot of it is the availability of infrastructure.
Although there was a white paper called "The Software Production Line," it was from Agile 2006,
we still were mostly deploying onto physical hardware or very expensive data centers and
such. It wasn't as easy to get the end to end. There were still a lot of silos in the
organizations. We own the hardware, and you can't have it, you have to fill out a report
that says why you need a virtual machine. Then we'll establish a virtual machine, and
now you continuously deploy to it. Whereas today, and for several years now,
it's a lot easier to provision that hardware in the sky. I fly a lot and I don't see
things in the cloud, but they say it's the cloud. It's just easier to get your hands on
the equipment to do it is a big part of it. So it needed a change in the organization
and not in the technique. Oh, yes.
That's interesting. Still, to apply this to a project, there must be some kind of overhead.
It's work that you need to do. So how big should the project be in order for this to make sense?
Yes, I actually contend that there is no low bar that as soon as you're doing it. Because your
continuous integration and continuous delivery are practices. They're not technologies that you add.
And so if you're creating new software and you start writing tests at the very beginning,
that's just a good thing because now you have tests.
If those tests are running and you know you're going to be deploying to a public cloud,
for example, then you should be deploying to that public cloud as often as possible to make sure
that you didn't break that process. So even with the very smallest applications, I do continuous
delivery on my website. When I update a blog entry, it goes to a pipeline that deploys it.
Nicki, you're working a lot with graph theory, graph databases.
How does that fit into continuous delivery?
One of the areas that we're looking at at the moment is how you can use graph theory in order to
get some interesting insight into your microservice architecture. So we've worked on a
few business-related projects, things like social networks and things like infrastructure networks.
But you can actually take some of that insight and apply that to microservice architectures.
One of the things we've done is looking to maybe hook into some of the observability tools,
things like Zipkin and stuff, and get some of that information out as to which microservices
exist within the system, who they're calling. Then applying things like community detection
algorithms and the like of that to actually work out what your architecture might
give you some insight into that, which can help you to improve what you have.
We keep referring to microservices and microservice architecture.
Have we been waiting for microservices to be the new thing before this made sense?
I think, in general, microservices is a complicated thing. Is very complicated
and it's getting more complicated as people actually
start building more services. People are struggling to actually understand
how these things fit together, where some of the bottlenecks are, and things like that.
I think the tooling and different techniques are coming out more and more to try and help
people do that. And I think this is one area explore. I think it was probably possible before,
but the problem is more obvious now that there are so many more people doing it that there
are different ways that we need to look at trying to get more insight.
So continuous delivery didn't wait for microservices?
Not really. One of the things I was talking about today is that
when we first started doing continuous delivery, it was still large monolith systems.
I don't want to make it that monolith bad, microservice good either, by the way.
If you're starting that greenfield brand new project that we talked about a moment ago,
to start it in a microservice type architecture where you don't know the business context
yet probably isn't the right thing to do. Probably is right to create a monolith for that first,
then figure out where your business lines are, and then that defines your services and so forth.
So we've been doing continuous delivery of monoliths for quite some time. There are projects
of a certain size. If the system itself takes an hour-and-a-half to deploy, then that stage
of your pipeline takes an hour-and-a-half to run, and there's no way around that.
So getting fast feedback about did this break our deployment and so forth became
much more challenging. Also, just organization, again, comes back to organizational structure,
people trying to get smaller pieces of ownership, it becomes harder. There are certainly ways to do
it. Microservices are not the only way. There are also component-based architectures and others.
Breaking it down makes it more complicated but it doesn't have to be if that makes sense.
Yes, exactly. I have a feeling that microservices are just,
in many ways, complicated. Things like what we're talking about here now. If that is true,
then I guess we're on a journey where microservices is just one stop on a journey.
So what comes after microservices? That's a big question.
I think at the moment there's a serverless versus microservices camp or a fight, not fight but a
difference of opinion. I actually don't see it that way. I don't necessarily see it as either
microservices or serverless. I do think that moving towards an architecture where you use more
managed services is the way to go. But I think they're also different architectures, serverless
architectures, truly service architectures, FERS-based and microservices, and they offer
different ways to do things. So in general, there is a move towards a more serverless and managed
service style of building components that way. I don't think microservices are completely going
to die. However, I think what people actually perceive a microservice to be is going to change.
So people have different ideas on the size and all these types of things. As more of the problems get
surfaced, I think it'll merge back into slightly bigger entities but more sensible entities and a
combination of serverless architectures as well. So what comes after continuous delivery though?
It’s funny because continuous delivery started "easy." You had a single thing that was going
through a pipeline, and you might want to do some tests in parallel, but for the most part, it was a
pretty straight path. Then we started adding more distributed-type systems where we didn't really
know which components were talking to each other. So the pipelines actually got a lot more complex.
What kind of testing are we are going to do to make sure that we're hitting a service API
that's not even available during our testing? They got really, really complex. What's interesting,
though, is as things solidify to where we really are understanding now that microservices,
but whether it be...I heard an argument the other day that serverless is a microservice. It's just
a different implementation. It's still a small thing that does one thing, and I don't know.
But as these things get smaller and more self-contained, continuous delivery is actually
getting easier. So we see the rise of software as a service for CI and CD where now we're
back to simple linear pipelines because our small little piece of code that we're going to put on to
serverless can be deployed in minutes or seconds, depending on how much testing you're doing.
The pipelines have actually gotten simpler, instead of the other way around. I'd see that
continuing, actually. What I hope to see next though is the pipelines learning from the work
that Nicki was talking about. So learning once it gets to production and we have true observability
and we're learning what we're doing, "Hey, we found that we're doing something here that we
really should be doing more compliance checks in the pipeline or different checks." Or, "Hey,
we don't need to do those checks but we do need to..." etc. So have the pipeline be considered
part of the system and have it evolve as we learn more about the system as a whole.
Will machine learning be part of that?
I think it could be.
Yes, certainly could be. I think in terms of the talk that I gave on graph theory and using that
to analyze your architecture, there's certainly elements of machine learning that would be able to
do some interesting things in some of the areas like grouping services and
understanding based on patterns of how services evolve over time, what might be interesting,
sort of, areas to look at. So in time, I think, certainly probably.
I'm looking forward to chapter two of this in one year. Thanks a lot for joining us today.
Thank you. Thanks very much. Thank you.