Paris Apostolopoulos on Developers Getting Closer to Production and Cloud Specialists

Daniel (00:03):

Hello everyone. I'm Daniel Bryant and I'd like to welcome you to the Ambassador Livin' On the Edge podcast. The show that focuses on all things related to cloud-native platforms, creating effective developer workflows and building modern APIs. Today I'm joined by Paris Apostolopoulos, a fellow Java developer and full stack engineer, whom I know from the London tech scene.

Daniel (00:20):

I've followed Paris's work for several years now and he always has a lot of interesting insight into how developers are adapting to what we're now calling the cloud-native way of working. Paris has worked across a range of organizations from small to large companies, so he's got lots of interesting experiences to draw from. I particularly enjoyed learning about his thoughts on how enterprise organizations are adapting their ways and moving to the cloud. If you like what you hear today, I would definitely encourage you to pop over to our website at GetAmbassador.io. I have a range of articles, white papers and videos that provide more information for engineers working with Kubernetes and the cloud. You can also find links there to our latest release of the Ambassador Edge Stack, the open source API gateway and our CNCF hosted Telepresence tool too.

Daniel (00:57):

Hello Paris. Welcome to the show and thanks for joining me today.

Paris (00:59):

Hello there. Hi. Nice being here. Thank you for the invite.

Daniel (01:03):

Could you briefly introduce yourself and your recent career highlights, please?

Paris (01:06):

Yes. So my name is Paris Apostolopoulos. I don't expect everyone to remember my surname. I'm from Greece, been working here in London for the past four years, almost five. I would describe myself as a software developer by heart that eventually fell in love with operations.

Daniel (01:25):

Today we're talking about developer experience and developer loops, so the capability to rapidly code, test, deploy, release and verify software. I'm typically talking about web based software, but happy to chat just general software staff. I wanted to ask you, without naming any names, could you describe your worst developer experience or dev loop from code to production?

Paris (01:46):

Like many people out there I've been doing this job for a long time, it's almost 20 years. If I go back in my career and compare how I used to be a member of a software team and how we used to code, deploy and go into production, a very easy answer would be that I think that the old times were a very bad experience in a way, in terms of productivity, in terms of continuous integration, continuous deployment, this very slow loop, this waterfall, let's say way of doing things.

Daniel (02:15):

What do you think about your best developer loop? Can you explain, or highlight, perhaps, some of the core capabilities that you really liked? You've already mentioned there CI/CD. Can you pick out a few things which you think are really important to that fast feedback loop?

Paris (02:29):

In the past we used to do even work inside silos. I can see that the things are changing now and I think they're changing in a very positive way for classical business developers or software engineers like me, where we have now the opportunity to come closer to production. CI/CD is part of this process. It gives you the framework of actually software engineers coming closer to operations. Then we can start talking about things like the cloud and eventually all of these nice abstractions that now we have available and how we enable us to eventually be more productive and be more reactive, let's say, in delivering faster solutions.

Daniel (03:10):

You mentioned something very interesting there about being close to production, being close to business, how important do you think it is for developers to understand business requirements, to the point that they can actually take full responsibility, say, for taking an idea and actually seeing it through to observing business value?

Paris (03:27):

For me, this is one of the epiphanies I had in the last four years. I was lucky enough eventually to join some companies that were fully on board on that vision. For me, it was one of the best things that happened for my career, because it's like seeing the light. I mean once I was given the opportunity, obviously without being an expert], I was given the opportunity to come closer to production, I think I gradually started becoming a better developer.

Paris (03:55):

It was the first time where actually I could totally relate and I could now see eventually how my flows as a developer, maybe my tech choices, maybe my style, maybe the libraries I pick or the frameworks at some point, especially on, let's say systems that they eventually required a lot of love and attention and eventually are public facing, how it eventually could affect the actual operation or the actual solution and the features provided to the end customer.

Paris (04:23):

So slowly this transformation started. The more developers eventually come closer to production, I think they increase their skills, they become better. It's not an easy path. It's not happening like that, but it's a journey that eventually I would be forever grateful. For me, it totally changed what my job would be, what I would do and eventually how the impact of my job would be to customers of actually the solutions I was creating.

Daniel (04:52):

Yeah. Super. I wouldn't mind to dive in a bit more to some of the operational things there you meant, Paris, because you and I, I think, they're very similar careers from that perspective. Before that though, I wanted to take a step back and look, say, at some of the architecture choices. I've seen you chatting on Twitter about microservices and things. How do you think this drive towards smaller, more modular architectures has affected the developer loop and the experience?

Paris (05:13):

Five or seven or eight years ago when this modular, let's say, approaches into eventually architecting systems started coming into play and eventually people started writing articles and eventually started preaching about it, I was one of the many that were saying that this is unnecessary. I've been spending two thirds of my career, eventually on technologies or eventually on setups or eventually on architectures that were not modular in a way. They were claiming that they were modular in their own respect. Maybe they had attempts of actually being modular internally, that's why we're discussing all about code modularities. Especially I'm coming from the JAVA world. It's something that it's a very famous topic within our community.

Paris (06:00):

Slowly though, and especially when you have the luck to work on, let's say, more high impact systems than, let's say, small scale applications that are going to affect systems, I could gradually see as I was switching jobs and eventually I was switching companies, how the practical approach of divide and conquer is actually the very, very core of this whole debate about microservices.

Paris (06:24):

As I get older, I tend eventually to become a bit more grumpy in terms of ... I think that in many cases our software solutions are not ideal. I mean many of us, we know the ideal state, but when you actually go into different places, you see that you have to make compromises and you have to cut corners because of different reasons and stuff like that. So for me, the adoption of microservices, or let's say a modular architecture, or as I say this divide and conquer, is mostly like an attempt actually to tame this mini chaoses that eventually software projects can become to for different reasons, for good or bad reasons.

Paris (07:04):

It's like a pragmatic, let's say, approach on solving or improving a solution. It's not the ultimate solution. You could have perfect micro services platforms, perfect monoliths, but it's like a solution where we'll meet in the middle. We actually divide and conquer the problem into smaller problems. Sometimes we satisfy organizational needs, sometimes we satisfy technical needs, but it's better to have smaller problems than one big that they actually cannot move. This is where I'm coming from and this is the hill I will die upon on Twitter.

Daniel (07:40):

Yeah. Nice. I like it. So coming back to what you said earlier, which I thought was equally as interesting as your comments there, was, it's important for developers to be operationally aware. As you get closer to production, you need to understand am I writing functions? Am I deploying onto Kubernetes? All these kind of things. How important do you think it is for developers to upscale and companies to allow them to upscale?

Paris (08:01):

That's a very good question. Actually, it's one of the struggles nowadays that I think a lot of engineers like me face in the current market. Obviously outside of the market, you have different peoples with different attendance developers that they don't want to upscale, or eventually they want to up skill on certain areas or they're not indexed in the ops. I belong to the group of people that I believe that, especially for this large community of the Java developers out there, it's one of the biggest developer communities out there paving the way into modern infrastructure, whatever that means. It's actually one really interesting way of actually up skilling and keeping up to date. I could see there that even for younger developers, it's a must. You cannot stay in your comfort zone.

Paris (08:51):

And especially for Java developers that we are now getting old. It's a wave of fresh air that actually gives you the opportunity to do new stuff and eventually learn new stuff. But at the same time, be more effective because this is all about, it's not about learning, assigning new technology just for the sake of it. It's actually bridging your skills and actually to deliver better solutions.

Paris (09:12):

Some organizers are already on board. Some others they claim to be, but they're not. Some others they like to have their silos again. I think things are changing rapidly and the more the cloud providers keep pushing services and eventually solutions, the more this wave is going to become stronger and stronger and eventually most of the organizations will try to get aligned with the new trend.

Daniel (09:37):

How much do you think cloud native technologies and platforms have impacted the devout? I'm thinking things like Kubernetes. I've got to create a container now. Put my JAVA up in a container, ship the container to Kubernetes. What's your thoughts on how that's affected your developer experience?

Paris (09:53):

I experienced this transformation gradually as I think every developer out there. Some years ago, somebody gifted us things like Docker, right? Obviously experienced since admin people will say that, which will be tools were only available, but obviously they were not available for the, let's say the masses of developers out there, or they didn't have the skills or the knowledge, or they were not easy to use whatever it is.

Paris (10:18):

So we started using these technologies like Docker and stuff like that, but there was always something missing if you ask me. And especially since I've spent a lot of years working with things like application server, enterprise architectures and things like that. It seems that eventually the exams that we had to do from this application servers, architecture eventually to smaller services and Docker and stuff like that, something was missing. And the breadth of things like Kubernetes and eventually other cloud native let's say solutions. Not only Kubernetes, I mean, we can see other cloud providers, eventually they are offering similar solutions now on top of their already existing services.

Paris (11:01):

Kubernetes answered most of the basic, let's say operational needs that we had in mind and reduced the friction and actually the time to production for mainly developer centric teams. And actually, I think it started to breaking down the silos, the silos of like, okay, you're the developer you just only write code, someone else pushes to productions and someone else maintains it. So suddenly we had the framework that actually gave us an entry to this world. And obviously we had to up skill, there's no doubt.

Daniel (11:34):

So you touched there sort of on it gave Kubernetes kinda gave enough primitives to solve a lot of the problems. Obviously you know my background, I'm very much interested in say, API gateway, service mashes, managing traffic. How important do you think it is for developers to understand and control traffic? Both at the ingress points, so the gateway and also service to service. Is that more a dev responsibility, more of an ops responsibility? What do you think?

Paris (11:56):

So in my book, the developers should up skill and eventually become better ops without saying that we don't need specialists. In my book, as a developer, the more you know about everything, about your system, your solution from top to bottom, from the edge, the database or the mainframe, the better. If this can be, let's say a combination of different people and different skills, in the same thing, that's fine as well. If it's only a dev team or whatever, that's fine. It's like you need to know, you need to have the knowledge. If that answers your question.

Daniel (12:31):

Yeah, definitely because you also played around with the Edge Stack API gateway. That's how I bumped into you, I think on Twitter and so forth. What do you think was good around Ambassador that enabled you to do something perhaps you couldn't before?

Paris (12:44):

I have to go back a bit before eventually jumping into things like Ambassador, because we talked a bit about Kubernetes and eventually lots of developers would have the same journey like me. The journey is not easy. It was painful. It had a lot of challenges, you had to up skill, you had eventually to accumulate a lot of complexity. You have to tame the beast.

Paris (13:07):

There's one thing saying on Twitter and eventually a blog post. Yes, I'm using Kubernetes for my personal project and another thing like using Kubernetes in production. So there are different phases that eventually you have to go through using Kubernetes and one of them let's go back now to ingress and stuff like that. It's like, how eventually you welcome all this stuff inside your clusters from the other world.

Paris (13:30):

For me, the journey with Ingress and Kubernetes eventually started very early because I was working on a public API project. So the API was a set of services deployed on Kubernetes stateless. That's fine. But always you had this, let's say concern, all right. What about this pipe that actually Ingress is all these questions inside my cluster. And it was not an easy journey to be honest, because like many people out there who started classic load balancers, we started making the same mistake. Like each service has its own load balancer and then without this it's not sustainable. Then we had security concerns. Then we had different other things that we had to discover them as we were working, because they were not always best practices there.

Paris (14:17):

So here we ended up eventually taking Ingresses and I have to be honest, Ingress is my least favorite, let's say, especially part of Kubernetes. Especially the way some of them... I mean, it's not like a blame, but I think it's like it tries to do a lot at the same time, simplify a lot, but then you have to obey on the restrictions of each cloud provider. And then you end up with defaulting Ingress that they have different, let's say behavior, and this is what always troubled me a lot.

Paris (14:53):

In the end, when you became, let's say very experienced and you actually knew what your needs were from your Ingress, let's say battle. At some point you were figuring out that Ingress is the standard, Kubernetes were not enough. So you always had to go through this journey, "Okay what else is available?"

Daniel (15:11):

It makes sense. And that's how you ended up at Ambassador and playing around with that?

Paris (15:14):

Yes. So at the time I think many people have the same choice. You have to play around. We found that becoming an expert on anything next or something else or traffic or whatever it is. What I really liked with Ambassador it's like, it was like something that obviously I had previous experience with Ingress and Kubernetes, but eventually it answered all my questions immediately and it provided a very low entry barrier, as we say. In actually to put it in and use it in terms of configuring it and pushing it into production or into other environments. So this is what I really liked. And that's why I picked, let's say this type of Ingress compared to what was already, let's say offered by the framework Kubernetes.

Daniel (16:06):

Now I'm with you, Paris. Very interesting. Very interesting. So we're coming to the end now. I wanted to ask you, what do you think the future of developer experience is going to look like? Because we've got more or less, like you said that they're getting a pushback now, we've got microservices, we've got functions, we've got Kubernetes, we've got cloud. Where do you think we're heading to as an industry? What might you think a developer experience will look like in say three years time?

Paris (16:27):

What I'm seeing is we're working in a new era of development, where actually cloud providers with all these nice features and eventually all these obstructions that are slowly hiding and eventually the operational concern that are starting. I think we're working through this era where actually developers will become, let's say, I don't know if they're going to become ops in a way, but they will become, let's say cloud experts in a way. Cloud provider experts in a way and will start building more and more stuff on top of these platforms. Some might argue, is it good or bad? But currently I think this is where we are heading to.

Paris (17:04):

To be honest for someone, for a developer like me, that we were like truly isolated in the past of actually one ID and one version control system and that just pushing code without having any chance of actually touching production. This new future is something very challenging for me. In terms of economies of scale and eventually if it's sustainable or not moving now into cloud provider specific solutions. I don't know, but things are getting there and I've seen eventually easier is that when you actually use managed services and you combine different parts that you don't have to worry of actually running on your own 100%. How it easier actually how the time to production gets shorter and shorter.

Paris (17:52):

Obviously each system has its own requirement and there's no one fit them all solution. But I think for the 80% of cases out there, this is where we can. This is going to be something like serverless or Kubernetes or whatever it is. I always thought that most probably Kubernetes paved the way. I can see Kubernetes actually been fading away. Many people talk about it, becoming like a framework and then other people eventually start building things on top of it. This is going to be serverless or something else. I don't know. We'll have to see.

Daniel (18:26):

Very interesting, Paris. Well, really appreciate your time today. Thanks very much.

Paris (18:32):

Thank you very much.