Transcript
Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.

Emily: Welcome to The Business of Cloud Native. I'm your host, Emily Omier, and today I'm chatting with Thomas Vitale. Thomas, thanks so much for joining us.

Thomas: Hi, Emily. And thanks for having me on this podcast.

Emily: Of course. I just like to start by asking everyone to introduce themselves. So, Thomas, can you tell us a little bit about what you do and where you work, and how you actually spend your day?

Thomas: Yes, I work as a senior systems engineer at Systematic. That is a Danish company, where I design and develop software solutions in the healthcare sector. And I really like working with cloud-native technologies and, in particular, with Java frameworks, and with Kubernetes, and Docker. I'm particularly passionate about application security and data privacy. These are the two main things that I've been doing, also, in Systematic.

Emily: And can you tell me a little bit about what a normal workday looks like for you?

Thomas: That's a very interesting question. So, in my daily work, I work on features for our set of applications that are used in the healthcare sector. And I participate in requirements elicitation and goal clarification for all new features and new set of functionality that we'd like to introduce in our application. And I'm also involved in the deployment part, so I work on the full value stream, we could say. So, from the early design and development, and then deploying the result in production.

Emily: And to what extent, at Systematic, do you have a division between application developers and platform engineers, or however else you want to call them—DevOps teams?

Thomas: In my project, currently, we are going through what we can call as maybe a DevOps transformation, or cloud transformation because we started combining different responsibilities in the same team, so in a DevOps culture, where we have a full collaboration between people with different expertise, so not only developers but also operators, testers. And this is a very powerful collaboration because it means putting together different people in a team that can bring an idea to production in a very high-quality way because you have all the skills to actually address all the problems in advance, or to foresee, maybe, some difficulties, or how to better make a decision when there's different options because you have not only the point of view of a developer—so how is better the code—but also the effects that each option has in production because that is where the software will live. And that is the part that provides value to the customers. 

And I think it's a very important part. When I first started being responsible, also, for the next part, after developing features, I feel like I really started growing in my professional career because suddenly, you approach problems in a totally different way. You have full awareness of how each piece of a system will behave in production. And I just think it's, it's awesome. It's really powerful. And quality-wise, it's a win-win situation.

Emily: And I wanted to ask also about security and data privacy that you mentioned being one of your interests. How do those two concepts relate to cloud-native technologies? And what are some of the challenges in being secure and managing data privacy specifically for cloud-native?

Thomas: I think in general, security has always been a critical concern that sometimes is not considered at the very beginning of the development process, and that's a mistake. So, the same thing should happen in a cloud-native project. Security should be a concern from day one. And the specific case of the Cloud: if we are moving from a more traditional system and more traditional infrastructure, we have a set of new challenges that have to be solved because especially if we are going with a public cloud, starting from an on-premise solution, we start having challenges about how to manage data. 

So, from the data privacy point of view, we have—depending also on the country—different laws about how to manage data, and that is one of the critical concerns, I think, especially for organizations working in the healthcare domain, or finance—like banks. The data ownership and management can really differ depending on the domain. And in the Cloud, there's a risk if you're not managing your own infrastructure in specific cases. So, I think this is one of the aspects to consider when approaching a cloud-native migration: how your data should be managed, and if there is any law or particular regulation on how they should be managed.

Emily: Excellent. And can you actually tell me a little bit about Systematic’s journey to cloud-native and why the company decided that this was a good idea? What were some of the business goals in adopting things like Docker and Kubernetes?

Thomas: Going to the Cloud, I think is a successful decision when an organization has those problems that the cloud-native technologies attempt to solve. And some goals that are commonly addressed by cloud-native technologies are, for example, scalability. We gain a lot of possibilities to scale our applications, not only in terms of computational resources, and leveraging the elasticity of the Cloud, so that we can have computational units enabled only when needed. So, if there is, for example, an high workload on the application, and then scale down if it's not needed anymore, and that also results in cost optimization, but also scaling geographically. 

So, with the Cloud, it’s more approachable to start a business that has a target in different countries and different continents because the Cloud lets you use different technologies and features to reach the users in the best way possible, ensuring performance and high availability. Something else related to that is resilience. Using something like Kubernetes and proper design practices in the applications, we can achieve resiliency in our infrastructure at a level that is not possible with traditional technologies. And then we have speed. Usually, a cloud-native transformation is accompanied by starting using practices like continuous delivery and DevOps, that really focus on automating and putting together different skills so that we can go faster in a more agile way and reduce the time to market. That's also a very important point for organizations.

Overall, I think there's a part of cost optimization, but at the same time, we should be careful because there are some hidden costs that sometimes are not considered fully. And that is about educating people to use new cloud-native technologies. We have some paradigm shift because some practices that were well-consolidated and used with traditional applications are now not used anymore, and it takes time to switch to a different point of view and acquire the skills required to operate cloud-native infrastructures and to design cloud-native applications. So, to make a decision about whether cloud-native migration is a good idea, I recommend to consider these hidden costs as well, not only the advantages but the hidden costs and the overall complexity, if you think about something like Kubernetes. For some applications, the Cloud is just not the right solution.

Emily: What would you say is a type of application that is not appropriate for the Cloud?

Thomas: As an application is not actively developed with new features, but it's in a pure maintenance phase and that is fully reaching the goals for its users. If it doesn't need to scale more than what it does today, if it doesn't need to be more resilient because maybe high availability is not that important or critical, then maybe going to the Cloud is not the right solution because you would add up complexity and make things actually harder to maintain. That is one scenario that I could think of.

Emily: So, basically, if it's not broken, don't try to fix it.

Thomas: Yes. So, cloud-native is the answer to a specific set of problems. So, if you don't have those problems, so maybe cloud-native is not for you because it's solving different problems.

Emily: So, would you say, the problems are if you need to really iterate quickly, develop new features, ship them out to customers?

Thomas: Yeah, if you don't need this agility because you're not actively developing features, or if it's small things that don't require so much speed or scalability power, then might not be a good idea. Or even if you don't have the resources, to acquire the skills required to design cloud-native applications and to manage cloud-native infrastructure.

Emily: What have been the biggest surprises as you've been using cloud-native technology and moving applications to cloud-native technology?

Thomas: So, I always think about how logging works. I think it's a fun anecdote that when you move to a cloud-native application, usually logging is managed through files in a traditional application where we set up rules to store those files. But usually in a cloud-native setting, like in a Kubernetes environment, we have the platform taking care of aggregating logs from different applications and systems. And these applications are providing these logs as events in the standard output. So, there's no files. 

So, one of the first questions for developers when moving to the Cloud is like, “Okay, now where's the log files?” Because when something goes wrong, the first thing is, “Let me check the log file.” But there's no log file anymore, and this is just a fun aspect. But in general, I think there's a whole new way of thinking about applications, especially if we're talking about containerized applications. So, considering Java applications, for example, they're traditionally packaged in a way that needs to be deployed on an application server like Tomcat. 

Now, we don't have that anymore, but we have a self-contained Java application packaged as JAR in a container. So, it's self-contained, it contains all the dependencies that are needed, and it can run on any environment where we have a container engine working, like Docker. So, developers take on more responsibilities than before because it's not only about the application itself, but it's also about the environment where the application needs to be deployed; that is actually part of the container now. So, we can see a flow of responsibilities that is different than before.

Emily: And do you think that that surprises a lot of organizations, that having developers need to take on more responsibilities is something that's not anticipated?

Thomas: Sometimes, maybe it's not anticipated. And usually, it's because when considering this migration, we don't consider those aspects of acquiring new skills, or bringing in, maybe, some consultants to help during the migration to help with all those practicalities, that from a high-level point of view, are not very visible.

Emily: Excellent. Tell me a little bit—I know you just wrote a book, so I was wondering if you could talk a little bit about your book and what inspired you to write it.

Thomas: The book is about designing and developing cloud-native applications using mainly Spring Boot, and Kubernetes, plus all the great cloud-native technologies that are available. The goal is to teach techniques that can be immediately applied to real projects, so to enterprise-grade applications, as much as possible. The cloud-native landscape is so complex, it’s so huge that it's impossible to cover everything, but I made a selection of all the aspects that I consider important and my goal is to try as much as possible to do things like I would do in a real application. So, what I would do daily in my job, so considering all those aspects that sometimes are not considered when teaching new technologies or new features, like for example, security. By the end of the book, the reader will have deployed a cloud-native system composed of different applications and services on a real Kubernetes cluster in a public cloud service. 

And besides this, I also aim at navigating these cloud-native landscape because when we look at this famous landscape picture on the website from the Cloud Native Computing Foundation, it can be really overwhelming, both for new developers, but also for experienced developers that are experiencing different techniques—maybe, you come from a more traditional practice and want to switch to cloud-native, it can be really overwhelming. So, I hope that with this book, I can also help the reader navigating this landscape. The idea for the book, I got it back in January, February have been conducted by the Manning publisher, and about spring, we started considering different ideas. And I was really researching into the cloud-native landscape, in particular, how to use Spring and all related technologies to build strong native applications, so I decided to propose a book about that, that have these two main characteristics of teaching, as much as possible, real-world examples and techniques, and also help the reader navigating the landscape. So, it will not contain everything about cloud-native because that would require several books, but I think it's a good primer for the field.

Emily: Excellent. And just, actually, a couple, sort of, basic questions I forgot to ask at the beginning, like how long have you been working with cloud-native technology? When did Systematic start using it and moving applications to cloud-native?

Thomas: In Systematic, we have different projects and products. So, depending on that, some teams have started even several years ago, and in my project right now, it's quite recent. But I've been working with Spring for, I think, five years; also with Docker. And it's my favorite set of technologies because I think provides a lot of features to solve many different problems. I also, in my spare time when I have time, I like to contribute to the Spring projects on GitHub. It's a great community, I think.

Emily: Fabulous, and who do you think would benefit most from reading your book?

Thomas: I think it would benefit experienced developers, back end developers with experience in developing web applications in a more traditional way that would like to move to cloud-native, either because their organizations are doing the migration, or because maybe they would like to understand more how it works, or they would like to find a job in that field. But also for junior developers that have some experience with application development, so some basic experience with Spring and Spring Boot, but would like to take the next step towards the cloud-native world also understanding what is that about, and what, actually, cloud-native means.

Emily: What do you think is the biggest misconception about cloud-native?

Thomas: I think there's two misconceptions that usually, I find that is… thinking that cloud-native is about containers and that cloud-native is about microservices. So, for the first case, containers are used a lot for cloud-native applications, of course. They're used directly when working at the Kubernetes level, for example, but are used also when leveraging platforms like Heroku, or CloudFoundry. In that case, it's not the developer building the container, but it’s the platform itself, but still, they are used. 

But cloud-native can also be applied to other different technologies, like functions, for example, in the serverless world. So, functions are not containers. So, in that way, I think it's a bit misleading to define cloud-native as containers. I think that containers is one of the technologies and implementations used for developing large native applications. But it's not the definition of cloud-native.

And microservices, also. I think it's wrong to imply that cloud-native means microservices because cloud-native applications are distributed systems. Of course, they can be microservices; it's a very used architectural style in the Cloud world, but I don't think that it’s a definition. Also, the CNCF previously had a definition for cloud-native technologies that was actually based on containers and microservices, and then they changed that. So, now they are listed as examples exactly because that is not the definition.

Emily: Fabulous. What about open-source, what do you think open-source and cloud-native’s relationship is?

Thomas: One example above all, like Kubernetes, that is open-source. It, I think, is the most popular project on GitHub with the highest number of contributions, if I'm not wrong. And I think that just explains everything about cloud-native because given that this is such a core project, and it's also the project that started all for the Cloud Native Computing Foundation, and it's a, now, very wide landscape of technologies. Open-source, I think it’s a very important part of it because it allows contributions from people around the world with different set of skills. 

And we're not talking just about coding, but also other aspects, like, for example, technical documentation. I know that lately there have been several contributions, for example, to the technical documentation for Kubernetes to improve the documentations and help people approaching these technology and understand the more complex topics. And from a security point of view as well, from a testing point of view, I think that open-source technologies open many possibilities.

Emily: Great. Well, I just have a couple last questions for you. The first one I like to ask all of my guests, what is a engineering tool that you can't do your job without?

Thomas: That's a very difficult question because I use so many tools. But I will say if I had to choose one, I would probably say my terminal window.

Emily: Excellent. And then, how can listeners connect with you or follow you? And in fact, where should they go to buy your book?

Thomas: So, they can find me on my website, thomasvitale.com, where I also write blog post about Spring and security. I'm also active on Twitter. My handle is @vitalethomas and on LinkedIn. But on my website, they can find all my contacts there. I repeat, thomasvitale.com. And the book is available on manning.com. That is the name of the publisher, so they can find it there. The title of the book is Cloud Native Spring in Action: With Spring Boot and Kubernetes.

Emily: Excellent. Well, thank you so much, Thomas, for coming on the show and chatting.

Thomas: Thank you.

Emily: Thanks for listening. I hope you’ve learned just a little bit more about The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up on LinkedIn: I’m Emily Omier—that’s O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.

Announcer: This has been a HumblePod production. Stay humble.