Transcript
Watt: This is the microservices panel. Chris spoke earlier about minimizing design time coupling in microservices. He's the creator of microservices.io, author of the "Microservices Patterns" book. He's also a Java champion, so really experienced in the microservices space. I look forward to digging into some of these areas with you. Of course, we've got James Lewis, one of the original people to actually coin and define the term or the architectural style that we call microservices today. James is software architect and director at ThoughtWorks. A member of the ThoughtWorks Technical Advisory Board, and the group that creates the Technology Radar, working to contribute to the industry adoption of open source and other tools and techniques. Then we've got Katie Gamanji. Katie is the ecosystem technical advocate at CNCF. Her focus is very much on the broader ecosystem and the tooling which can help microservices survive and thrive. She helps to grow and lead the end user community while bridging the gap with some of the other ecosystem areas, and the units there. Her past roles have included cloud platform engineer, and she's build quite a few platforms that have gravitated towards cloud native technologies, and that includes Kubernetes.
Are Microservices Still the Same Thing As It Was A Decade Ago?
I thought maybe what we can start off with is just a question on, actually, microservices as a definition. Does it actually still mean the thing that we think it means today? James, you coined the term a while ago, and if we think about agile, agile maybe doesn't quite mean the same today, as it does today. Are microservices still the same thing as it was a decade ago?
Richardson: What was it, James?
Lewis: I don't know. I should point out in the interest of complete openness, it wasn't just me, there was also Fred George. Adrian Cockcroft was talking about fine-grained SOA and microservices at the same time. I think it was just one of those sort of convergent evolution, whatever it's called. An idea whose time has come. At the time, it was very much a reaction to the technology focused approach to developing software at scale. We were focused on the technical layers and all the tools and technologies, and I think we really wanted to bring that away from that towards more of a business, to focus more on the business and bring more DDD into play, bring more of the business capabilities idea into play. In essence, I think of it really as it's a bit like extreme programming. Kent Beck was quoted as saying, "It's just doing all the good stuff all at once and turned up to 11." I think that's really what microservices architecture was about. It was taking a lot of the ideas that were present at the time, and putting them all together in one place. If you think about the guerilla service oriented architecture that was around at the time. Jim Webber originated that idea. Obviously, domain-driven design, looking at RESTful integration that was a big part of it and decoupling via hypermedia.
Does it mean the same thing now? No, of course, it's not. It's 10 years later. Semantic diffusion, as you say, Nikki, is a thing. Words change their meaning. Actually looking back, I think Martin and I would both agree, we got the name wrong. It's patchy. It's stuck. Really, it's not about size so much. Then when Martin names something, it tends to stay named.
Richardson: You should have gone with service oriented architecture, it would have eliminated some antipatterns.
Lewis: Of course, Dan North prefers replaceable component architectures, which is probably a more apt description of really what it's about. It's about designing for replaceability over maintainability. That was the original thing.
Common Antipatterns in Microservices
Watt: We've had quite a while having a go at microservices. There's been I think a lot of things we've done maybe right, but there's quite a few, what I would say, are antipatterns out there. What are your guys' opinions in terms of the most prevalent or common antipatterns that you see coming up over and over again, in terms of how people implement microservices and use them?
Richardson: I would say one obvious one is people believing it's like a magic pixie dust. Our engineering organization delivers software slowly, we'll just do microservices and everything will be great. Whereas in reality, if your software delivery is slow because of your process, because of lack of automated testing, and that you write code that's unmaintainable, then adding microservices to the mix will most likely make things worse. I feel like you actually have to clean up your act and raise the maturity of your organization before adopting microservices or simultaneously with adopting microservices. Assuming that microservices are actually the part of the solution, because somehow you just improve all the other stuff. That can be good enough.
Gamanji: I could echo that. I think this is a pattern that I've seen, when the adoption of containers got a bit more momentum. It's not about the containers, it's not about the technology, it's about understanding what your problem is, and actually getting to the core of it. Most of the time, this comes with a cultural shift as well, or development. It's not just about adopting a microservice, it's about you truly understand what you're trying to solve, and with that, try to apply some of the best practices. Talking about antipatterns, there have been a lot of use cases where microservices were adopted, but there still was code which was not very well maintained. It was still difficult to deploy. Automation was not part of it. Pretty much some of the functionalities that Chris already mentioned as well. Metrics of success as well is not something which is necessarily truly well defined. Some other organizations measure their success by number of microservices they have, which is not actually what you should aim for, isn't it? It's not about just the technology, it's about the cultural shift and truly understanding the root of the problem that you're trying to solve.
Richardson: There was once an organization I did some work with. The CIO read an eBook that I wrote, then got all gung ho about microservices, and top-down, 8000-person organization, he just announced that do microservices. That got translated into KPIs, which translate into bonuses and stuff, and it was like do a number of microservices determined your bonus, basically.
Distributed Transactions
Lewis: That's not what we meant at all. It's a previous client I was at, which is quite fun. This is around distributed transactions. When you end up with lots of services, and you end up having to coordinate transactions and have orchestration across these microservices, it can be a nightmare. Sam Newman and myself always said in our training courses, that the best thing to do if you think you might need a distributed transaction, roll those things together, because they probably need to be in the same place. I remember being at one organization where they had entity services, and then a business orchestration service that would coordinate transactions across these events, these services. The way they'd implemented it was as a ThreadLocal, so each call would be stored in a ThreadLocal in the stack. If they needed to then unwind the distributed transaction, they'd unwind the stack and issue rollbacks against each of these services. We thought, this is well done for a start, because that's quite a hard problem to solve. Then, what happens if you need two of them? What happens if you need two of these things in case you need to scale? They said, we've got a plan for that. We're going to bring the ZooKeeper in. Now they had all the problems, because now they've got the ZooKeeper problems as well. We all know it can be a bit of a ruse, because every time they were issuing a request against one of these microservices they had to also talk to ZooKeeper. It was interesting. Distributed transactions I also feel is something to watch out for, if you're building a microservices architecture.
Richardson: I gave a talk in the past, anyway, dark matter, dark energy, which was all about the conflicting forces that want you to decompose. Then the forces that cause attraction between services, and transactions is one key attractive force that resists the competition.
Watt: I think also seeing the distributed monolith is something that I've seen a fair amount of time actually in, in some of the clients that we work with as well, where there's just so many services and things like the entity service antipattern, I think is something when you're decomposing from a monolith into microservices, just having some of these very traditional concepts. Then you have to put everything together with transactions and all these things spanning multiple calls.
How Kubernetes Has Influenced and Shaped Microservices
One thing in terms of microservices that you can't get away with nowadays is Kubernetes seems to be going hand in hand with microservices, sometimes even interchangeably used in those sentences. How has Kubernetes influenced and shaped microservices as we've gone forward?
Gamanji: The introduction of Kubernetes was pretty much the adoption of containers. With Kubernetes, we have a container orchestrator which helps us to deploy those containers. It's not just about deploying the application, it's about some of the extra functionalities that Kubernetes brings. For example, we're talking about scalability. We have an horizontal pod autoscaler, which automatically will identify when the application needs to be scaled or not. It has readiness and liveness probes, which will make sure that your application is even restarted or your container is restarted to make sure that the service is up and running. We have a lot of other functionality such as declarative configuration, we have decoupling from the physical infrastructure layer, because all we have to think about is how you define your application within the Kubernetes world with resources such as deployment, replica sets, services, and so forth.
However, with Kubernetes, again, it's a mechanism to host an application. That doesn't necessarily mean that you can apply some of the best practices to the phase when developing your application. There has been many cases when entire monoliths have been deployed to Kubernetes, to the platform. It's going to run. It's going to consume a lot of resources. It's not going to be the most efficient way to run your application. It actually enables you to do that as well. With Kubernetes, I think it enabled for a faster, like let's put people into a good, positive perspective. It enabled for applications to be deployed faster, but at the same time, have some of these capabilities that I've been mentioning about: reachability, automation, scalability, readiness probes, liveness probes, and so forth. All of this actually is something which truly takes the shift from how you deploy your application to just deploy your application, containerize it. Actually, just package it with a tool such as Docker, or Buildpacks, whatever is the tool of choice in-house, and that is sufficient to actually have it ready to be deployed within a cluster.
Lewis: I was just looking at the ThoughtWorks Technology Radar and Kubernetes first appeared in assess in 2015, when I think Google's just open sourced it at the time. Microservices first appeared a little bit before that, and Docker appeared a little bit before that. I think the patterns we're talking about that Kubernetes enables, they're older patterns. I don't know if anyone remembers Dropwizard, it was a format of fashion a little bit. Previous to Dropwizard, there was a Java library, from the same individual, Coda Hale, called Metrics. That was a classic example of, put in a simple library, and then you've hit an endpoint and every application will have this library. Every application will have an endpoint that would give you your service uptime, it would give you your request-response latencies, and all that stuff. That's evolved into now out of your application and into the infrastructure. I think that's really fascinating actually, like the evolution of the essential complexity, remaining where it is in the business code. Then the accidental complexity, which was Martin Fowler's original point, that the accidental complexity is migrating into your network, into your service meshes, into your sidecars, into your container runtimes, into your orchestration tools. I think that's an interesting trajectory that we're going on. Maybe we'll end up with just a business analyst being able to drag and drop stuff together and then deploy into Kubernetes.
Is Kubernetes the Right Abstraction Level?
Watt: Do you think Kubernetes is the right abstraction level, or do you think we still need to build more of the ecosystem on top of it to make it easier for people to build microservices, because some of the stuff's quite low level?
Richardson: I have a few different points. I think first and foremost, the essence of what a microservice architecture is about is not really technical or infrastructure related. It's all about correctly identifying service boundaries, service responsibilities, their APIs, their collaborations. That is the essence of the microservice architecture. In terms of the numerous decisions that you must make when developing a system, those are the absolutely critical decisions. I think that another microservices adoption antipattern is it's inverting it and thinking, let's figure out our deployment technology, our tools and our literal technologies. That's very much an antipattern. It's really all about service definitions.
Where does Kubernetes fit in? I view it as a one of many possible deployment options. One obvious alternative would be serverless, like package stuff up as AWS Lambdas, and run it on AWS, or Google Cloud Functions? If that's not a good fit, then, yes, look at using a Docker based solution. ECS is one option there that can be simpler, or even Kubernetes. Then Kubernetes is actually quite good. It's available everywhere. It runs from a Raspberry Pi, to the public cloud, and everything in between. That's quite appealing. I view it as a deployment option, and not something that is intrinsically bound up to the definition of microservices.
Gamanji: I could actually add here a bit, because I think, with the popularity of Kubernetes, at the same time, we had another cultural pattern that has been quite prominent. I'm clearly here defining the DevOps. Again, it's not a procedure to deploy. It's a cultural shift of collaboration methods between the team. I think this is actually quite important, because when we're talking about defining what our service can do, especially in an architecture, we have myriads of services out there and have different teams taking control of them. How do you make sure that you have your APIs available out there? How do you make sure you have synchronization and awareness of how can you consume an API? If you have a feature request, how can you reach out to that team? This thing has been, I think, more emphasized by the DevOps culture, which introduced the infrastructure layer, where it lets the platform team to collaborate closer to the applications team to make sure that all of the needs that the service or an application requires, they're going to be made by the platform team as well. I think it's about defining your application, but at the same time, it's the next stage is how do you deliver it to the consumers. Sometimes there is required a better clarity or awareness of where your application is going to be deployed, so you can make the best of the infrastructure you have. That as well comes with a collaboration processing between the teams.
Lewis: It's interesting, isn't it, this idea of standardization as well, because we used to have a thing called domain application protocols, and you think about microformats in RESTful architectures and things. That's something that I don't really see teams talking about so much anymore. I think that's coming back to what you were saying, Chris, which is one of the important things are how do these things communicate? What are the APIs? What's the protocol by which I know I can talk to this other team over here? I'm using teams synonymously with service boundaries. I think that's something that seems to be disappearing. I don't know if anyone else has seen that. This idea that we're actually going to sit down and solve the hard problem, which is, what are the boundaries? What are the interfaces between our services, and let's agree on a common way of talking to one another? Because that's essentially the semantic gap. That's the semantic problem, which you can't really solve via technology, you can only solve that via people talking to each other.
Challenges with Getting People to Change the Organizational Side in Collaboration with the Technical Side
Watt: In some of the previous talks, there was quite a lot around the collaboration that's required to actually work out how to solve some of these challenges. Conway's Law also is something that often comes up in terms of designing your services either around the organization or vice versa. I think, quite often we find that with microservice architectures is to try and help organizations go faster, but often it doesn't happen, because the organization doesn't actually change at the same time. I don't know what your experiences are around that. How much challenges have you had on the human side of things to actually get people to change the organizational side in collaboration with the technical side?
Richardson: Humans, they're trouble. I use this concept of a success triangle. It's like in order to deliver software rapidly, frequently, reliably and sustainably, you need the combination of three things. From a process point of view, it's lean, and it's DevOps. From an organizational point of view, it's a loosely coupled network of empowered product teams. Then from an architecture perspective, it's a loosely coupled modular architecture, which sometimes is microservices, sometimes it's a monolith. You need all three of those in order to achieve the goal of rapid and reliable software development.
Lewis: It's like the old adage, when continuous delivery was a new thing and build pipelines were a new thing, you'd find people who'd spend months defining and building the perfect build pipeline, to get your software into production. We can get our software into production on demand, really fast. Great, what software? We haven't got any software. That's a classic [inaudible 00:22:47]. If anyone else has seen that, you definitely think, how good is your build pipeline? Because if you haven't got any working software to push through it, that's solving real business problems or producing real outcomes, then you're not going to deliver anything.
Gamanji: It's quite important to maybe do very well strategical upskilling in-house in terms of the engineering team. If we adopt a new concept to deploy applications or to create applications internally, I think it's quite important to create these internal standards that the employees can abide by. I think that's quite important, clear communication, transparency, and opportunities to upskill. I think the human problem is always going to be there. It's like we have different approaches to deal with it, though.
Lewis: Organizations find every possible reason not to change. Eli Goldratt years ago, I think it was in one of the [inaudible 00:23:57] of "The Goal," he talks about paradigm shifts, that it's the hardest thing for people in organizations to do is to shift paradigm. Something like a microservices style of architecture, adopting cloud native, that is a massive shift. It is a huge paradigm shift because it is about people. It's about team structures. I think we forget things like, for Amazon, Jeff Bezos didn't say build microservices. He said there was a bunch of other stuff, other constraints, other forcing functions, including things like have a direct line of sight to your customer, build product teams, as Chris was saying, have small empowered teams who manage everything themselves. It's all of that stuff. That is such a paradigm shift. Eli Goldratt says, you need three things to change a paradigm. The first thing you need to do is to have tried everything else within the existing paradigm. You need to be under a massive amount of pressure. You need someone to help you take the first step. Of course, ThoughtWorks is always available to help.
Richardson: Me too.
Watt: You, Katie as well?
Gamanji: Yes. Anything cloud native I'm here.
How to Influence Management and Leadership to Adapt Change
Watt: I don't know if any of you have come across the book, "Team Topologies" at all, and having to change your teams actually, as you evolve along your journey. Sometimes you might have full stack product team starting, but you might have platform teams in different interaction modes. I think that's something which is maybe lost along the way, because you find companies tend to set up and they say, this is our structure, this is how we're going to do things. It doesn't change as the organization, and as the architecture actually changes. Is there any advice or anything that you've seen for how to actually influence management and leadership to be able to recognize this and adapt?
Richardson: I think ultimately, not being profitable or declining profitability of a company is the ultimate motivator for most business people. Most organizations tend to not have such an immediate crisis, but if they do, then that's one of those really compelling reasons to change and transform. I once worked with one customer, they're a super successful company, but they had this aging monolith which was deployed on-prem. Because it was so large and old, they had difficulty testing it. It was buggy and customers were terrified to upgrade, because that meant downtime. That translated into a problem the business could understand, because it involved money. Then that actually motivated them to start looking at the microservice architecture, so they could carve pieces off, and then test them thoroughly.
Gamanji: I think this is the same problem space, but it can be applied to different domains as well. Chris has been talking about the adoption or maybe encouragement to use microservices. I've seen a very similar pattern when adopting Kubernetes as a platform. Again, it comes down to the same core principles, every single business would like to have a differentiator, which will allow them to deploy their functionalities to the customers as quickly as possible. For that, sometimes, when it comes to the platform, we can really make a really good use case that this is something that not only will reduce the cost for maintaining your infrastructure, but could enable your team to have more control, and maybe do some of the lifecycle management operations such as upgrading and updating the cluster easier, making sure that you have doors open to introduce new technologies, for example, service meshes that are out there. Again, having a business differentiator usually comes down to technology. At different stages within a company, it can be either the adoption of microservices, or it can be the adoption of containers and Kubernetes, or a call provider and so forth. I think it's an undergoing problem, which is, how can the company or the organization be profitable?
Lewis: Just on that topic of team topologies, there's another really great book, "Dynamic Reteaming." Heidi wrote this brilliant book. It's about different techniques for actually changing how your teams are structured. Not necessarily team topologies, it's from a platform team to a product team, to however it is. In terms of rotating people, keeping people fresh, keeping people's ideas, keeping people engaged. The best example of a company I've seen that does this and does it really well, is Redgate, who make database tooling. They originally did for SQL Server, now other databases are also available. They do this very successfully. They enable their people to move around between the different products. They almost have like a poster session, where every several months, developers will choose which product to work on, within reason clearly. I think that enables that for Redgate. I think that's the thing you don't see in many organizations, especially the larger ones, is they've got truly transformational leadership. They've built a learning culture, not just on their teams around technology practices and patterns and things, but around management practices and around transformational leadership. I think that's the thing that a lot of organizations are missing is this idea that we're not just stuck in our ways. We don't just do it this one way forever. We have to adapt. We have to learn. We have to learn new techniques, new styles, new organizational structures, and keep up to date in that field as well as managers rather than stick with the thing we've always done.
Watt: I think sometimes trying to have these initiatives done from the grassroots, it doesn't work unless you have the buy-in from management and leadership, really, because you can try till you're blue in the face, but if it's not understood higher up, it can certainly be a challenge.
The Next Evolution of Microservices
In terms of maybe the future of microservices, and where we're going, do you have any ideas on maybe what the latest trends are that you're seeing in either CNCF or in your clients in terms of what are these up and coming for microservices? What's the next evolution or the next thing that we should be looking at?
Gamanji: There are a couple of methodologies or tools that I'd like to mention here, when it comes to application development specifically. When we're talking about Kubernetes and cloud native, it has been all around the cluster, how you define your applications in configuration using Kubernetes resources, and so forth. However, there is a shift nowadays, where the focus is put on the application developers fully. That's how the open application model has been constructed, and it was outsourced two years ago in 2019. This pretty much allows to shift this focus from the infrastructure layer to the application layer. Most importantly, you'll be able to define your application in code in config, and you'll be able to deploy it across cloud providers. It's not just about Kubernetes, if you'd like to deploy it within a data center or a cloud provider, you'll be able to use this particular tool as well.
Another thing that I'd like to mention from the cloud native space, which focuses on the application development phase, is Gitpod. What Gitpod is, is pretty much a tool which codifies your local development environment. This is a huge enabler, especially if someone is creating or developing an application locally, they meet a bug, they will be able to codify that fully. It's all based on Git repositories, and you'll be able to wave just like one file, or even the Git repository, like everything is there. Someone else will be able to fully recreate that. It's going to be a mirror image of what the other engineer had. This portable development environments, this has been a focus as well.
In terms of the actual deployment of the application, of course, we have different methodologies, again, to enable that quicker push about applications to a production environment. This is where GitOps has been quite prominent. It is a mechanism which, again, you store the desired state of your applications within Git repositories. However, it changes the way a developer would deploy their application to a cluster. What I'm trying to say for all of these tools and methodologies, Kubernetes is here to stay. We have many surveys that are out there confirming this data. We have one of the latest surveys for the state of Kubernetes from VMware, and again, year to year they see an increase of Kubernetes being used in production. It's not just about infrastructure nowadays, we're trying to enhance the developer experience. This is where all of these tools and methodology that I've mentioned, can really flourish and they're actually gaining a lot of momentum lately.
Watt: James, what do you reckon?
Lewis: For me, the technology is one thing. That's evolving. There's been this giant explosion. I did a talk where I was looking back at where microservices first appeared and what came before it, and what comes after it. You get this massive explosion in monitoring, in logging, in container orchestration. It was just fantastic. That, I'm sure, will continue, because it makes a lot of people a lot of money as well for stuff. I think we still haven't cracked the stuff that's more around domains, the stuff more around business architecture. What the boundaries are, as Chris was saying. Doing a brilliant job of starting to codify, a lot of this is patterns, other people are doing similar work. For me, that's the message that still hasn't landed. It's about business. It's about team structure. It's about focusing on how to solve business problems. I think there's still maybe too much of a focus still on technology. I think we still need to correct that. Not many people still read Eric Evans' blue book. That seems to be declining in popularity, although Data Mesh is now bringing it back into popularity again, apparently. I think domain-driven design, business capability, and that stuff, are still at the heart of the field of microservices.
Richardson: Technology will continue to evolve. I feel like that's not the core of what microservice is about. This is a joke, but maybe XML will make a comeback instead of YAML. I just wanted to say that.
Lewis: Rather than tunnel XML in YAML, or in JSON.
Gamanji: We're going to replace everything with YAML here. There has been actually a project, which allows you to manage your applications using Excel spreadsheets. It can get worse if needed.
Richardson: Everything is just YAML. It's really funny. Actually, I wish Lisp was a configuration language, I feel that would be a much better approach. I feel like there's two levels to the problem. One, I totally agree with James about codifying best practices around design. I think domain-driven design, and the blue book by Eric Evans is key there, and related stuff. Then the other part of this is this whole monolith versus microservices argument. First off, we should stop using Twitter to discuss architecture. It's a terrible format for that. All of those debates, and if you post a tweet saying, monoliths are good. The level of engagement is off the charts. I wish we could all agree on where the monolith architecture is applicable, and where the microservice architecture is applicable, because clearly, they're both applicable and we just have to figure out when. I want that debate to just come to some conclusion.
Lewis: As a heads-up on that point, everyone. One of my colleagues, Neal Ford, is obviously quite well known in the architecture space, written a bunch of stuff around it. I think they've got a book, him and Mark, which is another book coming out fairly soon. I think it's called, "Architecture: The Hard Parts." They've talked very much, Chris, about this. They've got a really nice spoiler because it's their baby. They've got a really nice model around how to consider the granularity of service or granularity of the application. Keep an eye out for that.
Gamanji: It's about identifying what is the best architecture for your product to be deployed. At the same time, I'd like to remind that it's about iteration as well. What works for you at the moment might not work for you in a couple of years. Try to build for the problems in the future, which will help you to have maintainable code bases.
See more presentations with transcripts
