Transcript
Sven Johann: Hello. Welcome to a new conversation about software engineering. Today, I’m talking with Chris Richardson. Chris is a software architect and serial entrepreneur. He’s a Java champion, a Java One “rockstar” and the author of POJOs in Action. He was also the founder of the original CloudFoundry.com, an early Java PaaS for Amazon EC2.
Sven Johann: And that’s why we are here. Chris is the author of the book Microservices Patterns. And so today we are talking about service templates and service chassis. Chris, welcome to the show!
Chris Richardson: Hi, well, thanks for inviting me. It’s good to talk.
Sven Johann: Did I forget to mention anything about you?
Chris Richardson: No. No, thank you. I know I recovered. I guess the only thing I would add is that my business is consulting and training, so I help companies adopt microservice architecture.
Chris Richardson: And so if companies need help, please reach out to me.
Sven Johann: Okay. So service templates, service chassis, they are a solution, but what is actually the problem, before we dive into the solution? What is the problem they are trying to solve?
Chris Richardson: You know, it’s really funny you should ask that because I was just looking at microservices.io and I realized that when I wrote the pattern there, I actually didn’t define the problem.
Chris Richardson: Which is like really awkward, right, because I mean the whole point of a pattern is that it’s a solution to a problem. But yeah, I guess one way of thinking about the problem is, well, how do you enable a developer to quickly start the development of a new service? And that’s sort of fundamentally the issue you’re trying to solve.
Chris Richardson: I mean, in reality you could say there’s bigger things like, oh, we got to set up the GitHub repository, we’ve got to set up the deployment pipeline. So there are some additional things, but you know, when it comes to writing actual code, your job as a developer is basically, I want to write some business logic.
Chris Richardson: Right. I want to just go implement a business capability. But in order to do that, you’ve got to create a project with all of the code, and then there’s numerous things, right? Just like configuring the Gradle dependencies. That’s one thing. Which in itself is a non-trivial problem.
Chris Richardson: Like assembling a consistent set of Java dependencies that actually work together seems to be a really hard problem these days. You’ve also got to configure Gradle appropriately to set up all of the appropriate tasks. Then there’s configuring the frameworks that you’re using, and setting up data source connections and so on.
Chris Richardson: So admittedly something like Spring Boot with its auto-configuration takes care of a bunch of that. And that’s a good start, but usually you need a lot more than that. And then in a microservice architecture there’s a whole bunch of cross-cutting concerns that you typically need to implement.
Chris Richardson: You know, whether that’s say, okay, I’ve got a service with a REST API, I have to implement security, require all API access to be authenticated with a JWT, for example. You know, it could be a standard for your application architecture. Implement observability. Which is basic stuff like a health check, but you know, it also includes things like distributed tracing systems, logging, all of that basic stuff. And then finally, once you got all that in place, you can start writing some business logic.
Sven Johann: Exactly. Two days ago I had this kind of onboarding with a new team and, you know, everything you said. And then I was like, oh, you know, and we also use Argo CD for GitOps.
Sven Johann: Do you know that, you know. And you have to do that to deploy to a sandbox, and then you have to do license scanning and security analysis, dynamic and static state, all of those kinds of things. And everyone was like, okay, well, my head is exploding. I just want to deploy and Hello, World.
Chris Richardson: And actually just getting a set of Java dependencies in the right versions that work together, that can be a deeply frustrating experience. And then things like, we had the Log4j problem. And that requires a dependency upgrade. You got to upgrade to a new version of Log4j.
Chris Richardson: Which then sort of actually could trigger an upgrade of Spring Boot, which then actually the new version of Spring Boot requires a new version of Gradle. Right. Because the Spring Boot plugin has version dependencies on the Gradle version. So yeah. Sounds simple, but it’s just a bunch of work involved.
Sven Johann: Do you consider the problem, let’s say related to everything which is in the deployment artifact or are you also looking at, you know, maybe I need performance tests and I need to understand how I write those performance tests for my service, or if I want to connect to a database, if I have microservice, I probably get my secrets from a secrets store.
Sven Johann: So how do I get those out of a secrets store? And, you know, there is a lot of code, which is not really part of the deployment unit, but more of deployment pipeline, or maybe even other artifacts like tests.
Chris Richardson: Oh yeah, I guess all of the above. In a sense what you need to create is a Git repository that contains everything needed.
Chris Richardson: And that, for example, could actually configure the deployment pipeline, right? For instance, I use CircleCI, or there’s a .CircleCI directory that configures the pipeline or GitHub actions directory. And so on and so forth.
Chris Richardson: So all of that stuff including tests. Test support classes, testing strategies. And they can even be architectural concerns like, okay, as an organizational standard we’re going to use the hexagonal architecture. So a simplistic project, it would just be source main Java, right?
Chris Richardson: Whereas a more elaborate project would be a multimodule Gradle or Maven project where you’ve got a domain directory. That’s the core business logic. Then you have modules for each of the adapters like web messaging, database access, and so on. So even just setting up that kind of consistent structure and tying that back in with the build logic is another thing that you have to do.
Chris Richardson: Just to go, Hello, World.
Sven Johann: In the, let’s say in the monolith days, we had to do the same, but we just did it once. Right? And then it was done. It was just done. We could start. But in a microservice world, if we do it for one service, what is with the next and the next and the next?
Chris Richardson: Yeah, the monolith obviously just has one deployable unit, right? So you could say one RePub, whereas the microservice architect, you’ve got multiple deployable units. One obvious thing to do, which I guess I did in the monolithic world perhaps, was I want to start something new. I just copy/paste from an existing project.
Chris Richardson: Right. So you can do that, but you know, that kind of copy/paste … Just gratuitous differences between services based on say the whim of the developer at that particular point in time just creates a lot of inconsistencies and there’s a lot of work, right? So one solution to this problem is the service template pattern.
Chris Richardson: And that’s basically, you could say it’s a Hello, World service or a repository containing a Hello, World service that you can just clone and immediately start developing your application to a services business logic, and it just takes care of everything. It’s got the build logic, the deployment pipeline configuration, all of the code and the configuration for the cross-cutting concerns, plus some sample application logic as well. So you can just hit the ground running, right?
Sven Johann: So if I have to spin up a new service, I don’t have to spend days or weeks even to get all the things we mentioned in the beginning to get that running, I just clone the repository and that’s it?
Chris Richardson: Yeah.
Sven Johann: So that, actually it sounds pretty cool. So I’m actually, I have to say I’m a big service templates fan now. In every project, when I start a microservice project, I start with a service template. But I also run into problems with the service template because once I created it, it of course evolves.
Sven Johann: So I have my service, my Hello, World, and then I give it to Team A and I give it to Team B and I give it to Team C. And then, you know, we are in the project for some time. How can I avoid those kinds of drifts that, today I develop a version and in three months’ time, I know, oh, I could have done better with this service template. I have actually a few changes, which makes it easier to use and stuff like that. But it’s difficult to propagate all the changes to all the people who already use it.
Chris Richardson: Yeah. So each time you start a new service, you’re basically taking a point in time snapshot of your service template repository, which is likely to evolve over time.
Chris Richardson: I mean, it could just simply be upgrading our set of dependencies, right? Like, ah, Log4J emergency! That’s great. You’ve updated your service template, but all of the instantiations of it are still running the old version. It doesn’t help that. So there is this disconnect. I mean one possibility is that the actual services are forks of the service template repo.
Chris Richardson: So in theory, you could sort of do a Git pull to refresh, to pull the latest version and update it that way. So you could sort of leverage Git in order to minimize the work. So that’s definitely one possibility. But you know, if you take a step back you can view the service template as glorified copy/paste programming.
Sven Johann: That’s how I do it. Glorified copy/paste.
Chris Richardson: It’s the way. Doing a Google search and copy and pasting is how most development is done today. Right. But it’s generally a bad thing, right? I mean, eventually you realize we shouldn’t keep copy/pasting the same thing. Instead, we should create an abstraction.
Chris Richardson: And so the idea then is that then leads to this microservice chassis pattern. So that is a framework that contains ideally most of the build logic, most of the code and configuration of the cross-cutting concerns. And the service template is a much smaller Hello, World application that just depends upon the framework.
Chris Richardson: And depends literally in the sort of Gradle or Maven sense of the word. So your service template is this small thing. Then when you instantiate it your services are referencing a particular version of the microservice chassis.
Chris Richardson: So then that means that you make a change to the chassis, you then simply have to bump the version in each of the services. A one-line change and those services will then just get the new version.
Sven Johann: So one thing, would you recommend doing that already from the beginning, when we are still a little bit unsure how those libraries should look? Where my first version is not perfect?
Chris Richardson: I could argue it both ways. On the one hand, you shouldn’t design frameworks up front, they should really evolve from your experience.
Chris Richardson: Right. And actually from 30 years ago there was sort of this rule, you should basically write three applications and then create a framework that abstracts out the commonalities. So you want to be careful with big upfront design.
Chris Richardson: And then things that make me really nervous is sometimes I talk with organizations where it’s like, yeah, we’re going to build this framework and we’re going to build tooling around it. And they haven’t even implemented any services yet. Okay. I mean, like number one, you should actually have services working. Right. But then very quickly you should be aware of the copy/paste issue. And then be prepared to quickly iterate on this chassis concept.
Chris Richardson: You just don’t want to over-engineer any of this stuff, right. And there’s a tendency in organizations to, yeah, we create a platform team that does all this fancy stuff, but that’s sort of doing it backwards. You know, minimum viable platform concepts and so forth.
Sven Johann: Yeah. It’s tricky. So I would just start with good old copy/paste and let’s see if we get something working, get some experience, have a few services, trying it out. And at some point when we feel okay, now we learned enough, we could just start with building, let’s say the framework or the libraries.
Chris Richardson: Yeah. But you don’t want to leave it too late. Otherwise, you’re just creating a lot of technical debt.
Sven Johann: Yeah, I mean, what was it either Neil Ford or Rebecca Parsons saying the last responsible moment or something, that is really hard to find. Usually I’m always like, oops, I missed that last response.
Sven Johann: So now we have our templates. We spread it around across the organization. A couple of teams adopted it. We got some feedback. So now we build libraries and we have a nice chassis.
Sven Johann: And now I realize we have a new version of some library of our template or of our Hello, World application. And I’m wondering what should I do then, because I know the Google problem, you know, and I believe also the Dutch bank ING, they copied that approach that they say, look currently you are using library X, Y, Z. In version 2.1. And we are going to deprecate it in six months or in three months.
Sven Johann: So you have to update to a newer version in the next couple of months. Because after that, it won’t be available in, let’s say Artifactory for example. I always found that quite hard to just say, if you don’t update the library, nothing will work. And also the complaints I hear is that teams are quite busy constantly updating libraries instead of implementing business logic. Is that a correct observation or what would you recommend with updating those libraries?
Chris Richardson: I think there is this tension because, yeah, I just want to work on my business logic, right? But at the same time, things keep changing. New versions of various libraries come out. And then there’s the sort of cascading dependencies as well.
Chris Richardson: Just one issue I encountered the other day was I had a project that built with various Gradle projects, that built with various versions of Java. But I hadn’t tried it out with Java 17. And then when I tried it with Java 17, Gradle got this error. And then it turns out that you got to upgrade to some newer version of Gradle, but I was using some old version and I’d ignored the deprecation warnings about this feature that you’re using.
Chris Richardson: You know, like the way you those dependencies. So you upgrade to a new version of Gradle, then you’ve got to go through and change all of your build.gradle files. So that was one scenario where upgrading Gradle to support a new version of the JVM created some issues.
Chris Richardson: Another way is, as I mentioned earlier, you update Spring Boot, the Spring Boot plugin has dependencies on a particular version of Gradle or later. So if you upgrade Spring Boot, then up triggers an update of Gradle. So my big takeaway from that is you have to stay reasonably current.
Chris Richardson: Because the worst-case scenario is, going back to this Log4J fiasco, the easiest way to fix that in a Spring Boot application is just update to Spring Boot 2.6.2. And you need to do that quickly. But then that relies on having a whole bunch of other dependencies, including the Gradle version, that are reasonably current.
Chris Richardson: So sadly, I think it’s sort of a fact of life that you need to stay reasonably current just so that you can react quickly to security fixes or other things like that. So once again, one hopes that this microservice chassis framework can help, right? Because the chassis kind of defines in one place all of the dependencies, including say the Gradle wrapper version, the Spring Boot version that you’re using and so on.
Chris Richardson: So in order to upgrade to the latest and greatest, you just have to upgrade to the latest chassis. Now fingers crossed … One of the issues with a chassis is that … you could say it’s an opinionated framework, right? So if your service needs to do things that don’t quite fit with the framework, then there could be a potential mismatch.
Sven Johann: I’m just wondering, because that happens quite often. And I’m just wondering, how big is that problem? So I stole that from a German guy, Christian Deger. He once said we have this principle which we call “follow the trail.” We have a service template and the service template is kind of the trail which goes through the jungle.
Sven Johann: So if you follow the trail, your life will be easy, but maybe, in some circumstances, this trail is not for you. And then you have to go through the jungle and then things become obviously very complicated for you because there is no trail in the jungle and you have to come up with a lot of things by yourself, which a chassis is already giving you, and then you have to develop it by yourself. But that’s then your decision, that’s just how it is.
Chris Richardson: It’s sort of hard to talk about it in the abstract, but maybe the chassis could be sort of, I’m going to wave my hands and say modular. So that enables you to reuse parts of it as much as possible for your unique service.
Sven Johann: That is of course an idea. So you just skip certain, let’s say, parts of it and use them.
Chris Richardson: Yeah.
Sven Johann: So obviously if we use a chassis, things are getting consistent, right? That’s also something I like with that approach is we have something like, let’s say governance as codes. If you start a project, you have to develop all those concepts, and if they are written down, if they are documented, that’s good.
Sven Johann: But it’s better if you also can show a code.
Chris Richardson: Yeah, definitely.
Sven Johann: What’s your experience with that? Should you see it as a let’s say opinionated guidance which you can take or leave, or is it something where you say people should always follow that or the consultant’s answer, it depends?
Chris Richardson: Well I think in the context of say the microservice architecture, in order to be a production-ready service a service has to implement a certain set of attributes. API secured through a JWT. And then logging or observability and so on.
Chris Richardson: So there’s sort of a set of rules that a service has to follow in order to be a good citizen within this application and within your organization. So that’s a set of non-negotiable rules that can be written down.
Chris Richardson: And yeah, going back to your point about following the path through the jungle. The chassis is really that path that makes it easier to follow. And generally you should just follow it. But, if you don’t want to, well you have to go read the list of rules and implement them the hard way.
Chris Richardson: But you really should have a darn good reason for doing something different. Because on the one hand I think teams should be autonomous, but at the same time, they should not just go make gratuitous choices. Every decision that you make should be defensible. And should at some level get buy-in from the organization at some level.
Sven Johann: I had an interesting discussion a couple of weeks ago where people said, oh, you know, our goal is to have the highest autonomy for our teams. And I was like, no, I don’t think so. Because one team, they basically built their own platform by themselves. So we offer a platform and they just said, ah, you know what? We are not interested in this Kubernetes stuff. We just do our own thing, you know, with Lambdas and all that. And I said, look, autonomous teams are not the goal. The goal is to be fast, right? And if you’re totally autonomous and you do everything by yourself, you’re not fast. So if you follow the trail, you are fast.
Sven Johann: So maybe you should follow the trail.
Chris Richardson: It’s interesting. I feel like you need to achieve a balance between kind of conforming to the rules and autonomy. One of the most interesting examples of this was a few years ago, I was at the DevOps Enterprise Summit.
Chris Richardson: And there was a talk by some people at Target about how they manage their technology roadmap. You know, like the list of technologies that you can use within your organization. And this was, like the traditional way of doing this is, yeah, you’ve got some yeah, big-brained architects that you have to go beg and plead.
Chris Richardson: And a year later they’ve approved the use of some technology that everyone else has been using for three years. But with Target, they had a really interesting scheme and it sort of leveraged GitHub actually. So the list of approved technologies was a GitHub repo, and you could submit a pull request saying, I want to actually change the list of approved technologies.
Chris Richardson: And then that would trigger the usual PR review mechanism where the rest of the organization got to debate. You actually had to debate the suggested thing. And so it was sort of consensus based. And you’d hope that people would be quite rational about this. And it was sort of interesting and the level of agreement needed depended upon the impact of the technology that you are adopting.
Chris Richardson: So if you were proposing a new database, that probably went up to the CIO level and I think they reviewed that monthly or quarterly. But if it was some random JavaScript framework, the other JavaScript developers could go, yeah, sure. And to me that was a great way of managing technology within your organization.
Chris Richardson: So it was very grassroots, bottom-up driven for the most part. Because you can have problems. One example, I was doing an architecture review for this client, and their primary technology was JVM. Maybe it was MySQL. That was the sort of technology stack.
Chris Richardson: But one developer just decided to create a Rust-Postgres-based service. Just because. And it’s kind of interesting, but organizationally it’s like, what the heck? You’ve incurred the organizational overhead of supporting yet another database type, and you can debate the merits, but you know, Postgres, MySQL … I mean, you pick one. You don’t have both. And then you’ve picked a non-JVM language. Why?
Sven Johann: You always find reasons, right? If you want to try out a new technology, but yeah, does it really help the client? It probably only helps this developer interested in Rust.
Chris Richardson: Yeah. So if that company had applied say the Target model, he would have submitted a pull request saying I want to use Postgres. And the answer would probably have been “no.” If I want to use Rust the answer would probably be “no,” too. Unless there were some unique requirements, like super low latency, couldn’t incur the overhead of Garbage Collection, therefore Rust is okay.
Chris Richardson: Another more reasonable example would say, okay, I know we’ve been using Java, but hey, let’s have a look at Kotlin. Because you do want to experiment with new technologies, but you want to have technology candidates that are justifiable.
Chris Richardson: And Kotlin would be something to experiment with. And hopefully the rest of the organization would be, oh yeah, sure, try it out.
Sven Johann: So in the Target model, you said about the database some C-level person decides, and about JavaScript frameworks is it then the frontend community, or who decides what to adopt there?
Chris Richardson: More or less, something like that. I can’t remember the details. But you can imagine that depending on the grade of the impact of a particular technology, the higher up it needed to go.
Sven Johann: I will look up the talk and also put it in the show notes.
Chris Richardson: Yeah. It’s like Target DoJo technology governance, something like that, the DevOps Enterprise Summit.
Sven Johann: Cool. So I’ll look it up. One thing I was also struggling with ever since with my service templates, actually I only did service templates, no chassis, was not adapting like a product management mindset. So we developed it, we threw it to the teams. Of course we try to collect some feedback, but now in hindsight, I think the documentation was pretty good, but now I have the feeling a little bit more product management would have been better all the time.
Sven Johann: Offering also “professional services” and establishing some, you know, feedback cycle with the development teams and things like that. What do you think about this product management mindset? Is it necessary and if yes, how much?
Chris Richardson: Good question. I mean, maybe it just depends on the degree of it. In some ways it’s a service template and chassis is non-trivial in many ways and yes, it probably needs good documentation and probably needs an owner.
Chris Richardson: Maybe across the organization it’s just like a community of practice of people who are from multiple teams who contribute to the chassis. But as opposed to having a dedicated chassis team, I kind of feel like that’s probably overkill. But having a bunch of people who have ownership of that, I think makes sense.
Sven Johann: So either it could be, let’s say part of the platform team, but maybe better is a couple of developers from each team who try to maintain it.
Chris Richardson: Yeah. Well, I guess it just depends, like … is it a full-time job? Probably not. But it’s one of those periodic things. Well, once again, going back to the Log4J problem, you would’ve been really busy. There’s a lot of people who are probably still super busy dealing with that mess. Then there’s issues with balancing the needs of feature development with the needs for chassis development.
Chris Richardson: And certainly in this case, chassis development takes priority over everything else.
Sven Johann: Any dangers you see when applying service chassis?
Chris Richardson: Well, maybe the issue is it’s more sort of an organizational thing where if it’s really, and this is sort of a generic issue with platforms, right? Where if it really is sort of a bottom-up approach where the chassis and the template evolve, it’s very much driven by the needs of the team.
Chris Richardson: I think that’s a good thing. Whereas if let’s imagine you have the platform team and there’s a risk of over-engineering and imposing this overly complex solution on the development team. Once again it’s sort of a platform anti-pattern. I would worry about that.
Sven Johann: Yeah. I’ve seen that, true. You see it and you think, okay, I’m not going to use it because it’s too complex.
Chris Richardson: We tend to gravitate toward technology and toward platform stuff because it’s nice, it’s exciting. and it’s tangible, whereas business rules and users, those are messy, nebulous things. So there is the risk of that, but I mean, we always need to remember that the focus is basically implementing our domain logic. And you could say the UI, the user experience. Those two things are what’s important and everything else is just sort of supporting stuff.
Sven Johann: True, true.
Chris Richardson: There’s a lot of stuff. With hexagonal architecture, all the stuff around your search, on the outside of your services, it can be quite complicated, even though it’s fairly boring, relating to the actual business logic that you’re implementing.
Sven Johann: Are there any criteria regarding organizational size when I should start to think about it? I mean, I could imagine if we are ten people in the project and we just write a couple of services, we are just good to go with copy/paste or something. But if we are 150 people or 500 people, it’s probably better to adopt this approach?
Chris Richardson: In many ways the organizational size kind of ties back to whether you should be using microservice architecture or not. For the most part, the microservice architecture is when you have a team of teams developing services. And I suppose you could say if you’ve just got a handful of services, probably not, but once you get ten or more … The need just grows probably super linearly with the number of services you have.
Sven Johann: Is it the Monzo bank with 400 microservices? They probably have something like that.
Chris Richardson: Oh yeah. That service granularity is a super interesting issue. I’m very much in favor of just having a service per team. Unless there’s a really good reason for having more.
Chris Richardson: There’s various motivations for having more, like, oh, we need to use a mixture of languages. For detection services. Yeah, most of it’s in Java, but then we’ve got the machine learning model executing in Python. Two services there, right? One team. But interestingly, what I’ve noticed is there’s a really common what I would argue is anti-pattern of having a service per developer.
Chris Richardson: You need to talk to a team and it’s like, you know, three people, well, let’s say five people. Each one of them has their own service. And it’s almost like the team is really itself a team of one-person teams. You know, and each one’s responsible. And a lot of that just comes from taking the service metaphor or concept just too far.
Chris Richardson: There’s a lot of things that should just be a library or module. Don’t just automatically turn it into a service because you have a service template and chassis that makes it easy to spin up and be set up now. But yeah, one service per developer is a super common anti-pattern that I’ve seen in numerous organizations.
Chris Richardson: And then Monzo bank, that’s even better. I think it’s ten services per developer?
Sven Johann: I don’t know. But I know they have a lot of services.
Chris Richardson: I think at one point they had 150 people, 1500 services, right? And I’m sure there’s good reasons. So I don’t want them yelling at me, but it’s not a model that I would recommend to an organization.
Sven Johann: Don’t just copy/paste the solution if you don’t have the same problem.
Chris Richardson: Yes.
Sven Johann: So I have one last question and I call it specific hassles. So Netflix, they just said everything which is deployed in our infrastructure has to run on the JVM, and Monzo bank says you have to use scope, for example. What about companies, which just say you can use any technology you want, or you can use, let’s say, Java, Go, and JavaScript, and you can run your stuff on an elastic, Kubernetes service, or you can use AWS Alumni.
Sven Johann: Is it still worth thinking about service chassis if you need to support lots of languages or at least more than one language or more than one platform?
Chris Richardson: I think the short answer is yes. With the assumption that I guess in a sense you end up with needing to have multiple chassis, multiple templates, right? For Java, for Golang. And then for sort of particular environments as well.
Sven Johann: Which is a lot of extra work.
Chris Richardson: And I feel for that reason … I mean there are a number of thoughts. Like certainly when it comes to languages, I feel like you should in general want to make your technology choices in a very careful way. And you shouldn’t make gratuitous arbitrary decisions. Like, oh, I’m just going to use Alexa for this just because I feel like it. I mean, it’s fun. But, you know, from a business point of view, it’s not helpful. It’s not a good approach. Plus it actually ends up incurring a lot of costs. Because yeah, if you pick some unsupported language, then you go back to the problem that the service template solves, right?
Chris Richardson: Oh, we got to implement all this build logic, this cross-cutting concerns stuff. So on and so forth. And that’s a lot of overhead. So you really need to make wise technology choices. And most organizations do. I mean, I remember I have talked with companies that, for historical reasons, half the company was using Java and half of it was using Python to basically implement business level services.
Chris Richardson: And that just seemed less than ideal. You really need to pick one. Right. And then, say, Python, excellent choice for anything involving math and machine learning and that kind of thing. But to have your order management logic implemented in Python and then your delivery management logic implemented in Java. Why?
Sven Johann: To me, it feels like one of the big sells of microservices is there is some sort of macro architecture. Everyone needs to follow that macro architecture, but on the micro level, in your service, certain things, you’re just free to choose.
Sven Johann: And yeah, people say, I just want to use the language I want to use. You know, and if I want to use Whitespace or Brainfuck, why not? And now extreme, of course nobody’s doing that, but let’s say I want …
Chris Richardson: Someone, somewhere, is using that. I mean, you’re right. I mean, in a purely technical sense, right? Provided the service is a good citizen within the application architecture and provided it implements the necessary API, then everything else about it is a technical detail that is encapsulated and free to change. And you could make gratuitous decisions.
Chris Richardson: On the other hand, from an organizational point of view, there’s sort of these non-technical issues like staffing. One client I worked with a few years ago, they had a Scala stack. And it worked well for them, except in the geography where they were based. They couldn’t hire any Scala developers, and the whole team was actually a bunch of expats from other countries.
Chris Richardson: And that kind of situation is great when you’re small, but imagine you get a whole ton of venture capital and you want to rapidly scale up to hundreds of developers. You can’t manufacture a hundred Scala developers. And so it doesn’t even matter, the technical merits of the technology.
Chris Richardson: It doesn’t matter that Scala supports monads and effects and other functional – I’m going to call it mumbo-jumbo – when you can’t hire the people. Apologies to the functional programming community. So from an organizational point of view, using Java, for all of its boring warts, and its lack of monads, functors, and God knows what else, that’s a much better choice because you can go out and hire a hundred Java developers and actually build product that you can sell.
Sven Johann: Hmm. That’s true.
Chris Richardson: Right. And that’s a huge concern. Or one person knows one technology and they leave, that’s a problem for the organization.
Chris Richardson: Another example is you pick a certain kind of database – from the API level makes no difference, right. The database is encapsulated. But from the operational perspective, the ops team now has to manage that database. So it’s not just the concern of the development team. It’s now a concern of the platform team as well.
Chris Richardson: So there are these broader issues that really constrain the technology choices that you can make.
Sven Johann: Yeah, it’s something some people don’t want to hear. Too many technology choices, but I agree. In one project I’ve been in it was not actually programming languages, but they said, oh, we have no environments, but we have all those teams developing their services, but they all do it in their own little sandbox, but there is no integration environment or no production yet.
Sven Johann: And you know, everyone is free to choose the deployment pipeline of their choice. And for me, it was like, no, we have no time. We have to hurry up. We have to do this in two weeks. And if everyone is busy for two weeks choosing an appropriate technology for deploying, we are going nowhere.
Sven Johann: So we constrained now the choice to, back in the days, GitLabCI. So everyone has to use it and that’s, you know, it’s fine. So then we are fast. But it was not really what had been sold to the people. Sold was free technology choice. But I would say in a lot of cases, it makes no sense. Without constraints you’re not going anywhere.
Sven Johann: All right. Cool. So my questions are answered, I have to say. Thank you very much. I start my day tomorrow with a fresh view on service templates. Actually, currently I’m working on one, so I have to rethink a couple of things after we talked.
Chris Richardson: Oh, good, good. I’m glad. I’m glad this was useful.
Sven Johann: Yeah, I think so. I think so.
Chris Richardson: One other plug is I actually have a Manning liveProject series which is currently in beta. And the goal of the liveProject series is actually to first build a microservice template, a service template, and then a later project actually refactors it into a chassis and so extracts the chassis out of the template.
Chris Richardson: So hopefully that will be available from Manning soon.
Sven Johann: Okay. Okay. Cool.
Chris Richardson: And creating that was actually really thought-provoking. Gave me a lot of stuff to think about. A lot of the ideas I brought up today kind of were crystallized by going through that exercise.
Sven Johann: Okay. Cool. When do you expect it to be available?
Chris Richardson: That’s a good question. I don’t know the timeframe. I mean, it’s in beta, right? Actually the beta might be finishing any day now, actually. So, so real soon.
Sven Johann: Cool, cool. Maybe I ask next week or in two weeks for a link, or is that too early?
Chris Richardson: Yeah, I don’t know. I don’t know the publisher’s process, because this is the first time I’m creating a liveProject. So it’s a different workflow from creating a book.
Sven Johann: All right. So yeah, I want to thank you. I want to thank our listeners, and Chris have a nice day.
Chris Richardson: Yeah, thanks. You know, it’s 8.15 in the morning, the sun is shining, so … pretty good. Thanks. I enjoyed the discussion. Thank you.