DOP 83: Using Spring to Develop Cloud Native Applications

Show Notes

#83: When Spring Framework appeared on the scene over 18 years ago (October 1, 2002), the public cloud was just a glimmer in the eyes Amazon, Google, and Microsoft. Fast forward to today. Spring has adapted over its lifetime and still is considered the industry standard for Java development. Today, we speak with the Thomas Vitale, author of Cloud Native Spring in Action from Manning Publications.

Order your copy of Cloud Native Spring in Action and use the discount code podparadox20 to save 40%!

Guests

Hosts

Links

• DevOps20 Slack Workspace

Rate, Review, & Subscribe on Apple Podcasts

If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!

Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!

Transcript

Thomas: [00:00:00]
Because when you start moving from the old way of developing applications to a more cloud native one, and when you start having a more strict collaboration between different professional figures, like developers, operators, testers all together to achieve the same goal, it gets really challenging at the beginning, but together working as a team and having the end goal in the end every challenge can be overcome.

Darin:
This is DevOps Paradox episode number 83. Using Spring to Develop Cloud Native Applications

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:33]
Now, if you were listening from last week, we spoke with Olaf from Vamp and we're headed down to sort of a little bit decidedly different route for us. Sort of. We have another guest with us this week and his name is Thomas and he is the author of Cloud Native Spring in Action from Manning. Thomas, how are you doing today?

Thomas: [00:02:01]
Hi, thanks for having me on your podcast. I'm Thomas Vitale and I work as a senior systems engineer in Systematic, a Danish company where I design and develop software solutions in the healthcare sector. I like working with cloud native technologies and I'm particularly passionate about application security and data privacy.

Darin: [00:02:23]
You're a Spring developer, but you're doing a lot more than that. What is a day in the life of Thomas look like? He rolls out of bed at 4:00 AM. He goes for a three mile run. Is that true?

Thomas: [00:02:38]
Yes. Let's say that is true.

Darin: [00:02:40]
Well, we'll say that.

Thomas: [00:02:42]
Yes. Yeah.

Darin: [00:02:43]
What does it look what's a real day look like for you during work?

Thomas: [00:02:46]
My day at work is quite interesting since I started being involved also in the deployment part of our software. Before I was only working on the development part. Everything became so much interesting and I felt like that we were achieving so much more than before, because once you have the experience of how it is deploying an application and what happens when you merge your pull request in the repository, I think you get a whole new perspective about the work that we do. As a result, you get to have a better result, a higher quality result. I am involved in working on new features for the softwares we were working on and also the deployment part specifically, in the last few months, we are transitioning towards a more DevOps setting. We are going through this transformation that is quite interesting and I'm involved in that as well. Not only coding with Java and Spring, but also deploying our applications.

Viktor: [00:03:54]
Here's a counter question from Darin's. How do your nights and weekends look like?

Thomas: [00:04:01]
Right now, I'm very busy writing the book. So I spend a lot of time working with that. I live in Denmark. It's nice to hang out with friends and enjoy the good weather when it's actually good and if it's not good, it's always fun to do some activity over the weekend.

Viktor: [00:04:21]
Okay, so you seem relaxed. That's good. I was afraid that the answer to my question would be, Oh, you know, I'm on PagerDuty the thing that I just deployed doesn't work and then things like that. So your weekends are family, not putting down the fires then, right? That's good. You're in a good place.

Thomas: [00:04:41]
It's really good. Yes.

Darin: [00:04:44]
So, how is it that it's that good? Because it sounds like you're now transitioning from being sort of the monolithic type application organization into something that's a little more, dare I say it, agile. Why are you so relaxed? Why are you so calm? That doesn't seem right.

Thomas: [00:05:07]
Yeah, that's a very interesting question. I don't know, but at least I'm very passionate about all these aspects of developing and managing applications and especially in the sector where we work, that is healthcare. I know the end goal is providing value to people that work in a sector, taking care of people in need. That really motivates me in my daily work. The transformation is not easy. It's very challenging. Not only because it requires a whole new organization of the daily work, but also a new set of skills. Because when you start moving from the old way of developing applications to a more cloud native one, and when you start having a more strict collaboration between different professional figures, like developers, operators, testers all together to achieve the same goal, it gets really challenging at the beginning, but together working as a team and having the end goal in the end every challenge can be overcome. I would say I'm quite positive about that.

Viktor: [00:06:21]
So what makes an application. There is the word cloud native in you mentioned a couple of times, and it's in the title of the book. What makes it cloud native? How is that any different from non-cloud native?

Thomas: [00:06:37]
Yeah. Right now it seems like cloud native, like a lot of other words in our field, is a buzzword, right? So everybody is talking about cloud native, but what is cloud native? It's always challenging to answer the question, because I think like DevOps, like depending on who you ask, then you get a different answer. But I spent a lot of time coming up with a definition for my book, something that set the scene for the reader because it's important. If we talk about cloud native, but what is exactly that, and for applications, drawing from the definition of cloud native technologies from the Cloud Native Computing Foundation, I think that it's about developing applications that are loosely coupled, that are scalable, that are resilient, observable, manageable, and secure. The whole development and deployment process should be tied with a set of practices, including continuous delivery and DevOps, at least that's what I wrote in the book. That's the starting point of understanding all the different techniques and practices, patterns that are used to develop applications.

Darin: [00:07:52]
Tell us a time when that didn't go so well. Maybe it's not on this project. Maybe it's a different project that you've been able to deal with. What was that story like?

Thomas: [00:08:06]
I think one thing is when you have a division between the department taking care of developing the application and the department doing the deployment and the operation stuff, because it's hard to bring ideas to the market in a very fast and high quality way. Along the road, it's likely that you get some obstacles and you get some misunderstanding or maybe miscommunication because the people involved in developing a feature, then have the concept of a feature being done when it's delivered as a code, like to the main code repository and then it's someone else's job to boot that application in production, but that code becomes useful provides value when it's in production. When that doesn't happen, there are some challenges because if it's someone else taking your code and deploying it, he doesn't have all the knowledge about what the code is supposed to do and also vice versa when working on a feature, maybe not considering completely the operational aspects. You might end up building the wrong thing or build the right thing, but in the wrong way. This is a scenario where many things can go wrong and then you get a phone call at night because production is down or something is wrong.

Darin: [00:09:42]
have you received that phone call in the middle of the night?

Thomas: [00:09:46]
I've been lucky, not in the middle of the night. No.

Darin: [00:09:50]
But in the middle of the day, right. You get a notification that something's gone sideways.

Thomas: [00:09:56]
Yes.

Darin: [00:09:58]
So what happened next after you got that notification?

Thomas: [00:10:03]
When there's something going wrong in production, the first thing is to bring the system back to a satisfying operational state so that users can keep using it and right after that start investigating the root cause so that it can be prevented from happening the next time and fixing the root cause as soon as possible. But I think it's very important not to spend too much time trying to maybe get all the details about what happened, but just enough information to have the system usable and available again.

Darin: [00:10:46]
I started working with Spring back in the very long time ago, early 2000s. It was still Spring framework 1.2 and I've worked with it off and on some since then, but I'm going to go back to what Viktor was saying a few moments ago. What makes Spring today cloud native?

Thomas: [00:11:11]
That's a good question. So cloud native is how we design and develop applications, in this case in Spring, as the most used framework in the Java ecosystem provides all the tools necessary to achieve that goal and to get applications that have those attributes that I mentioned before, like scalability, resilience, loose coupling. In the years, Spring evolved a lot, and now it's a really huge ecosystem with a lot of different tools and libraries at our disposal. So what makes Spring cloud native? I can mention several examples. For starters, we have Spring Boot as the basis of everything that provides a way to have one single self-contained application that can be run in any environment, so you're not depending anymore on an external web server like Tomcat, but we use an embedded one now. The whole Spring Cloud suite that provide projects for managing externalized configuration or functions, reactive programming that it's very efficient way of programming in the cloud. Streams and event driven architectures. Spring has really several tools that can provide all you need for a cloud native application and very soon will be released officially also a new library to have native Spring applications. So running on something like GraalVM.

Darin: [00:12:52]
Well, I think that's probably their answer to something like Quarkus. That's what they're having to compete now against that which Red Hat released. .

Thomas: [00:13:03]
I think it's a good competition and Quarkus is a very recent project, but it grew a lot in a very short time. So besides those two, we have also a few other frameworks that are writing in the Java ecosystem. I think every once in a while, there's always this discussion about Java being dead or Java not being suitable for modern applications or the cloud. But I think right now we are seeing a lot of progress and fast paced innovation in the Java ecosystem and Spring and Quarkus are I think the two main actors in this context.

Viktor: [00:13:45]
It's been a while since I used Spring. Back in the days, it was downloading half internet for Hello World. Is that still the case?

Thomas: [00:13:56]
No, I would say that things improved. It's so easy to get started with an application. Spring Boot in particular focuses a lot on productivity. So you can go to this Spring initializer website, start.spring.io, select all the dependencies that you need, and you immediately get a fully functioning application.

Darin: [00:14:19]
Let me see if I answer your question, Viktor. It doesn't download the full internet anymore, but it downloads about 75% of the internet. The one thing though, and I saw Viktor, one of our mutual acquaintances tweet this the other day. He's been writing Go for a very long time now. Like the past couple of years, and he's now recently had to pivot back to Java and he says he misses a lot of the Go things, but the thing that he does not miss is the dependency management from Java compared to Go.

Viktor: [00:14:54]
Oh, yeah. That's the biggest complaint about Go I think. Dependency management simply is a bit painful or not. I mean, we can have a long discussion on that.

Darin: [00:15:05]
In the applications you're writing today, are you writing those to be deployed on Kubernetes? Are you running them on bare metal? What is your target without giving away trade secrets, unless you want to

Thomas: [00:15:18]
Yeah. I can say that we have all our applications containerized as Docker containers so that gives us a lot of flexibility because once you have containers, you can run them on any platform or environment where there's a container runtime, including Kubernetes, but not like limited to that.

Viktor: [00:15:40]
What else is there? Okay. Now you struck, struck a nerve. What else? Swarm? Mesos?

Thomas: [00:15:48]
Yeah. Okay. So if we're talking about orchestrators, I mean, it's without any doubt, Kubernetes is the most popular, the most used. Also I think on GitHub, it's the project with the most contributions or the most like open issues. I don't remember correctly, but I mean, it's incredible. It's also, it's a recent project and now it's Kubernetes everywhere. Also the most used platforms as in a platform as a services that were used to deploy applications like Java applications are now switching to a Kubernetes model. So now we are building everything on Kubernetes. So it's kind of the common layer or the way that we communicate everywhere. We have a ground infrastructure with Kubernetes, and then now there's a lot of innovation between different cloud providers to provide their services on top of Kubernetes. And I think that this where going to see a lot of innovation in the future while still having Kubernetes as the middle layer almost everywhere.

Viktor: [00:16:53]
So that kind of, it makes me curious. And what I'm going to ask is mostly based on me, not following that part of the world for awhile now. So in the past, frameworks like Spring Boot tried to give a complete solution. Logging, monitoring, basically everything an application needs was provided by a framework. Now, when you move to cloud, when you move to Kubernetes, when you move here and there, usually we are trying to focus now only and exclusively on business logic and forget about everything else within applications. Is that statement valid for Spring, for example? And I'm asking because I'm not following really, that basically everything is out of the framework and it focuses only on the business logic?

Thomas: [00:17:40]
No, it's a very good question because yeah. Now Kubernetes is so popular and Spring is going in that direction as well. But before Kubernetes being popular, Spring I think it was the first one providing a full set of projects and libraries that you could use to deploy your microservices taking care of everything. So in the Spring Cloud project, we have libraries for service discovery, for example, something that is managed by Kubernetes now, or for circuit breakers that now we use Istio or a service meshes for that, or maybe load balancing. So at that point in time, we didn't have something like Kubernetes and Spring provided all of that. Also a famous project is the Spring Cloud, a Netflix project with several open source projects developed originally by Netflix and included in Spring because at time we didn't have something like Kubernetes, so we needed that and now there's a shift not only from using Spring specific libraries for something that is now provided by Kubernetes, but by doing that, we're also implicitly moving the responsibility because the developer doesn't need to configure for example, the load balancer as a Spring application. It's something else doing that or service discovery. So we gain a lot of advantages, but by doing that because Kubernetes really lets the developer focus on the real business logic and all these infrastructural aspects are provided by the platform. Plain Kubernetes or a platform on top of Kubernetes.

Viktor: [00:19:17]
As you said, we're increasingly moving towards smaller applications, microservices, call it whatever you want. What is happening with the popular frameworks from before like Hibernate that were basically, and then all those big libraries that are designed basically for large applications. Are they now out of the game or are they reinventing themselves?

Thomas: [00:19:43]
I think they're still in the game, but we are experiencing also some new techniques and patterns, for example, considering the reactive programming way of developing applications. We recently saw new actors in the field, like talking about databases. We have now not only JDBC as a way to connect a Java application to database, but we have a reactive library managing nonblocking communications with the database, for example. We have a lot of focus also on events and on functions for deploying functions on a stateless platform. So of course in that scenario, something like Hibernate is not the best choice maybe because what we are looking for when we deploy function in a stateless platform is that we want really fast start up time and we don't want too many resources because one of the great advantage is having the application or the function scale to zero, so it's only active when there's something to do. Something to process. And then it's down without us having to manage the server or having something always on. So of course, depending on the case, we have maybe other choices, but I still think that something like Hibernate will continue be a very important actor, at least in enterprise applications.

Darin: [00:21:16]
Why do you think that?

Thomas: [00:21:19]
Because in the enterprise world, I think that sometimes it's easy to get caught in the latest technologies, but I think that we also need to consider stability and the business value of any technical choices. So I don't think that, for example, it's always a good idea to move to the cloud or to reinvent the applications to be cloud native or now we have the extreme that sometimes, no, let's not do microservices, less extract functions from microservices. So something even smaller. So there must be a reason, right? So we have a goal of providing value both to the customer and to the business. In the current landscape, we have really so many choices that we didn't have before and it's great, depending on the requirements, we can choose what we need, but I can see something like Hibernate disappear like that.

Darin: [00:22:22]
I guess my point for that question is if you're doing application development today and you're not doing it in a reactive way, and you're doing it in a blocking way, why are you even developing an application? That's just asking for trouble.

Thomas: [00:22:38]
I was thinking more about all the applications that we have right now. I agree when we start a new project, of course, it's easy to evaluate what we have right now, but we have a lot of applications around the world that keep businesses alive every day. So it's not that immediate like moving an entire infrastructure, for example, from using Hibernate and some old style relational database and do the migration entirely at least.

Viktor: [00:23:19]
You're kind of referring to applications that are in maintenance mode, that are just going to receive new requirements, new features without really changing their architectural aspects in any form or way, right?

Thomas: [00:23:33]
Yeah. Yeah. I would say maybe I'm cautious thinking that for new projects, of course, that makes sense, but for existing projects, it depends. Yeah. It's not a satisfying answer, it depends, but I, I really believe that because there can be many different situations.

Viktor: [00:23:53]
That's always a tricky subject for me. Of course, vast majority of workloads are legacy in one way or another. That's simply the reality of where we are. I'm always curious about what is the optimum amount of effort you want to put in that, right? Let's say that a legacy app is using JDBC, right? Should it move to Hibernate while maintaining its size or should it just not go anywhere and just keep existing as is? And I'm always struggling in finding answers to those questions.

Thomas: [00:24:31]
yeah, it's also a matter of managing the complexity. Because when we think about something like microservices and the startup, like just getting started with some new service, then already bringing up a lot of complexity for managing many microservices and having reactive every way. So instead, maybe you start focusing on the business logic that will be the core value of the startup. You start spending a lot of time handling all these complexity around. Maybe that can come later. So knowing where you're going, but going there maybe step by step. I really like for example, Sam Newman, when talking about microservices in his workshops, he always start by stating, like when not to use microservices and what to consider before getting started with that. And I think it's a general thought that we should always have and ask why we are thinking about some technology and whether it's the good choice for what we're trying to achieve in that specific point and time.

Darin: [00:25:47]
so basically do everything reactive, unless you've got a lot of money coming in on the product you're already selling. Don't touch it and keep making the money. Right. It always comes back to the money. Follow the money.

Thomas: [00:26:01]
Yeah, but yeah, I think it's complicated. There's many factors in a decision

Viktor: [00:26:08]
of course it's complicated. If it's wouldn't be complicated, not none of us would have our jobs.

Thomas: [00:26:13]
True.

Darin: [00:26:15]
Very very true. Okay. Again, the name of the book is Cloud Native Spring In Action. It is currently under the Manning Early Access Program, MEAP. I remembered it this time. The link for the book will also be down in the show notes or in the description. Also, you can order it and get 40% off by using the code podparadox20. That's podparadox20. That code will also be there and save you a neat 40% off, whatever the pricing is. Now at the time you're listening there probably five chapters already done. You can always check out the GitHub repo that has the source code in it as well. Again, the link to the book will be down in the description and don't forget that to use that highly specialized coupon code podparadox20 to save 40% off. Thomas. Thanks for hanging out with us today.

Thomas: [00:27:16]
Yeah, thanks for having me.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.