BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Anubhav Mishra and Nic Jackson on Platforms, Developer Workflows, and HashiCorp Waypoint

Anubhav Mishra and Nic Jackson on Platforms, Developer Workflows, and HashiCorp Waypoint

In this podcast, Anubhav Mishra and Nic Jackson from HashiCorp sat down with InfoQ podcast host Daniel Bryant. Topics discussed included: the benefits and challenges of creating application platforms in the cloud, the need for effective developer workflows, and the role of the new HashiCorp Waypoint tool and service meshes within workflows.

Key Takeaways

  • Many organisations are investing heavily in creating application platforms, but the real value is derived from delivering business functionality to end users. Look for opportunities to standardise and build upon existing platform technologies.
  • Defining and building against key abstractions is vitally important in a platform. Avoid searching for the lowest common denominator, and focus instead on abstractions that will enable an effective workflow.
  • HashiCorp Waypoint is a new open source project that provides developers a consistent workflow to build, deploy, and release applications across any platform.
  • Developers should bake-in observability and security to their applications from day one. The platform should facilitate this; service mesh technologies can provide insight into services, and also provide transport security and service identity.
  • Many of us are now building distributed systems, but the software engineering tools have not yet caught up with the new challenges presented by this.

 

Transcript

00:21 Introductions

00:21 Daniel Bryant: Hello, and welcome to the InfoQ podcast. I'm Daniel Bryant, news manager at InfoQ and director of DevRel at Ambassador Labs. In this edition of the InfoQ podcast, I had the pleasure of chatting with Mishra and Nic Jackson from HashiCorp. I've previously worked with Nic back in 2014 at the UK based online retailer, notonthehighstreet.com, where we were building platforms based on Apache Mesos and AWS, this is pre Kubernetes. I've known Mishra for a long time via his open source work and his influence at HashiCorp. He's my go-to person for all things Vault and Secret Management. We've all been attending various online events over the past few months, such as HashiConf, KubeCon and KubeCon Plus. And every time we bump into each other, we have fascinating conversations on topics such as the importance of cultivating developer workflows, building platforms using open source and cloud technologies, and how best to implement continuous delivery. This time we decided to record the conversation. So, hello and welcome to the InfoQ podcast, Mishra, Nic.

01:10 Anubhav Mishra: Hey.

01:11 Nic Jackson: Hey. How are you doing? It's great to speak to you, Daniel.

01:14 Daniel Bryant: As always with you both, too. Now we've all been friends for a long time, but could you introduce yourself to the listeners please?

01:19 Anubhav Mishra: Thank you so much, Daniel, for having us on the show. This is really a privilege. So, my name is Mishra. I'm the technical advisor to the CTO at HashiCorp. I work in the office of CTO on strategic projects. This might involve partnering with major cloud providers, on projects and also doing some open-source work, some advocacy work. As part of this role, I get to look at emerging technology areas and see where they are relevant to HashiCorp. My background is in computer engineering, so I studied computer engineering in university. I've worked in operations, engineering roles, also software engineering roles, so I empathize with both developers and operators. Currently, right now, I'm in the process of writing a book called, Getting Started With HashiCorp Vault. The book, it's tailored towards beginners into security and learning Vault. First few chapters of the book are out on Leanpub, if anyone's interested. More recently though, I've been involved in projects like CDK for Terraform and HashiCorp Waypoint, and both these projects are HashiCorp projects which are fully open sourced.

02:19 Nic Jackson: I'm Nic Jackson. I'm a developer advocate here at HashiCorp. Before that I was working running engineering teams, software engineering, software development. Great fun with distributed systems, written a book on microservices and a little plug for next year, I've got a book coming out on microservices, but specifically service mesh patterns and practices. So, you'll be able to catch that on O'Reilly in the new year.

02:46 What value does a good platform provide to engineering teams?

02:46 Daniel Bryant: Super, super. So, just to set the context, as you were talking there Nic, you and I have actually worked together in the past building platforms, and I've had many chats over the years with Mishra around the same topics. That's why we thought today would be a fantastic opportunity to explore some of these challenges. But could you both share your thoughts on the value a good platform provides to the ultimate goal we're all aiming for, is delivering value to our end users, right?

03:06 Nic Jackson: So, I think it's simple. And I think you've got to look at what your role is within the organization, where do you derive value? And I would argue that you derive value from delivering unique functionality or features for the business. And I don't believe they are the platform, because what you tend to do, whilst you may think it's unique, I believe we're all involved in exactly the same action across every different organization, which is pretty much building the same platform. When really we should be writing business functionality.

03:39 Anubhav Mishra: Yeah. I think I agree with Nic's take on that. Daniel, you and I have talked about this a lot, is that being at these really large conferences when we would meet at the expo floors and things like that, and I would look at you and you and I both were like, "Oh my God, there's so many things out there." And I feel like bringing all of these things into organizations that have a certain structure, a certain business goal, it always is difficult to expose them in a way that's useful. A lot of people try to expose three of the tools or technologies that might solve the same problem, but it is very inconsistent in organizations across different teams.

04:16 Anubhav Mishra: People are using different types of languages, especially in polyglot organizations, it's even more difficult, because certain teams are biased towards one language or the other. So, I think a platform, it really brings in a lot of key pieces that would help maybe standardize some of this exposing of technology, that's useful for a business org. I think that's the main goal. And what that solves is, developers writing code, not worrying about how you're doing some complex network routing, or how are we exposing a key value store into the organization? That's someone else's issue.

04:49 Nic Jackson: And just to clarify as well, because I've just been sitting there listening to Mishra and realizing that, wow. Did I just give a really click baity statement in my opening thing there? But the two things around this, one is that the last thing I did before leaving my last job was set up a platform team. I also believe that there is a very good reason why we're all building platforms, and that's because nobody else has provided one for us. And I'm hoping we're going to get into chat about that because I've got some pretty good opinions on that.

05:17 What does a modern platform-as-a-service (PaaS) look like?

05:17 Daniel Bryant: I think that's a perfect set up, Nic, because my next question was going to be, what does a modern platform look like? And I'll frame it for the listeners by saying, a lot of us talk about platform as a service, the classics, Heroku, Cloud Foundry. I've definitely pushed back at them at times thinking they're cookie cutter, one size fit all type thing. I've actually come to realize the value of these things more and more now. Heroku is actually awesome. I may have pushed back on it. But what are you both think are the quintessential elements, if you like, of a modern platform, modern PaaS?

05:45 Nic Jackson: I think the first thing is that it's beyond just running an application. And I think there's some incredibly good tools. I mean, Google Cloud Run, I think is a wonderful tool. AWS has got some great stuff going on with Lambda, if you want to take the end of the serverless side. Azure has got some great stuff going on with Container Engine, the container storage and running container instances. DigitalOcean's just launched a really great little platform, which allows you to run containers, databases, and things like that. But I think platform is more than just running the container. It encompasses the entire of the developer workflow, from deployment of the code, potentially even the application framework that you're using, and also right through the end stack from providing insights into how the application is running.

06:33 Anubhav Mishra: Yeah. I agree with Nic. And I think the thing that always excited me about building platforms, I guess I didn't go that back in my background, but I was an operations engineer and I've been a software engineer as well. So, seeing both sides of this wall that we talk about a lot in dev ops, and we did end up building platforms on multiple different schedulers. For example, Mesos to start off with, and then we went to the Kubernetes and things like that. But we were also using multiple Amazon web services at my previous job for maybe just for doing some pops up and doing some event streaming and things like that. And that was fine as well. So, for me, what's exciting about platforms is it's an opportunity to harmonize some of these things that happen that might be really good for certain use cases, but may or may not work for other use cases.

07:19 Anubhav Mishra: So, you pick and choose the 95% in your company, so what would be that 95% that can get the job done for pretty much everyone that's in the organization. And I think it's a lot more than technology. It's a lot more about people coming to an agreement of what that service contract is, and creating that service contract, creating what that service template or whatever you want to call, looks like. And once you have agreement, it actually becomes beautiful. And we saw this in organizations previously, at least at one I worked with. With a bunch of people with a view of a really small team, but somehow we got the right people, key stakeholders together, and asked them to come to an agreement, and luckily we did. And we really started off the microservices journey with the right foot forward.

08:04 Anubhav Mishra: And the interesting thing about platforms is that once you have that kind of consensus and you have that interface to really create services, and as Nic pointed out, that it's beyond just containers. It could be other things, right? It could be certain applications require you to run on a dedicated machine, certain applications it's much better to just consume the cloud providers version of it and things like that. So, once you have that really clean interface, you can swap things in the background, and people shouldn't worry about it. And this is one of the things that I really loved in my previous job. That we went from Mesos to Kubernetes with minimum disruption to people. I think I've given an InfoQ talk about this. The title was really clickbaity, I guess.

08:45 Anubhav Mishra: It was, Moving from Mesos to Kubernetes Without Anyone Noticing. That was the title of the talk. You can search it. But the idea was to seamlessly move from thing. But we had that pass in front of the scheduler. We didn't really leak those details down to the developer, and that really helped us in the overall establishing a standard of the company.

09:03 Nic Jackson: I think that's a super important thing about a platform. I think, as a developer, you should have mechanical sympathy of the infrastructure that you're running on, but you should also be abstracted away from its dependency, like Mishra was just explaining. And having the ability to port your app from one version of a platform to another is actually really important.

09:22 Is multi-cloud viable for most organisations? And to what degree?

09:22 Daniel Bryant: And I'm 100% on board with what you gents are both saying. One pushback I have had is folks almost trying to standardize the lowest common denominator. I see this with data stores a lot. It's like I could use some Amazon, Azure, Google, pick your poison. I could use one of those, but I'm actually going to put a layer of abstraction or a facade on top because I don't want any of this leaking through. And I'm like, think of the business use case here. Are you really going to migrate away from that? So, I'm totally playing devil's advocate.

09:48 Nic Jackson: Yeah.

09:48 Daniel Bryant: I'd love to get your thoughts on that.

09:49 Nic Jackson: I can say that in... How old am I now? I've been working in the industry 25 years this year.

09:57 Daniel Bryant: You're old.

09:57 Anubhav Mishra: Too old.

09:58 Nic Jackson: Yes. Exactly. And I need to retire. You're absolutely right. But regardless, right. In 25 years, I could count on zero hands, the number of times that I've actively migrated an application from one database to another. I have never done it. And I'm not saying that's the case for everybody, but I think it's a fairly unique use case. I mean, the thing is if you're bound to say, MySQL or Postgres or ElastiCache, or Redis or something like that from an application integration perspective, if you're running on GCP or if you're running on Azure, or if you're running on AWS, all of those clouds have got no problem in providing you a Postgres or a MySQL compatible database. So, do you need that interface in your app layer? I don't know. The reason I question that is I find that sometimes that complexity adds to the cognitive load of the developer as opposed to simplifying it.

10:51 Anubhav Mishra: Yeah. I think that's a good point. I think this is an interesting question, rather than giving some really complex analogy I'll just give you a practical example. So, let's say you do choose Amazon as your cloud platform. Let's say your organization does have the pedigree to go Multi Cloud, and you do want that redundancy for some reason. For example, you might think that Google's ML services are better. So, you're like, okay. We're using Google's ML services. We're going to be our containers and Java applications are going to run on AWS. And you end up choosing, let's say, Aurora, which is a really amazing SQL service on a managed SQL service on Amazon. And it gives you really good performance. You don't need to run a cache in front of it. It's really, really nice, and it's cost efficient for your use case. And it's giving you the performance that you need. Do you really want to abstract that and then say, Oh, at some point what would happen is we might move to on-prem and we might need to basically replicate the same service on-prem with the same type of SLA?

11:53 Anubhav Mishra: It's impossible to do. It's very, very difficult for you. Yes. You could move to a different cloud with a similar service, but even then I think, most services that are managed, they give you so much more if you directly use them without any interface and so on. But I think, to that, what I say is that, okay. If you can avoid using a driver in your application code that the managed service is offering, so that way at least don't have the code where you need to migrate the code at this point if you move. At least you're clean then. You don't have anything that's leaking from the cloud provider in your code base. I think that actually prevents you from some of these issues, but I think you're going to find a happy medium, but at certain points you might need to just use the service as is, and not actually try to... I think that's just too complicated at that point.

12:39 Nic Jackson: I just had a thought though, because I think with databases, I'm still going to maintain what I just said, but then what I'm thinking is, what if it's secret or a piece of configuration or an event? I think maybe that's slightly different, because I don't think you're dealing with standards anymore. Like the event bus that runs on SQS is different from Google's Pub/Sub and stuff like that. I think if you're running multi-cloud than it might make sense to have abstraction.

13:03 Is it a case of finding the correct (cloud) abstractions for platforms?

13:03 Daniel Bryant: There is abstractions available, Nic. Like CloudEvents jumps to mind. I was chatting to the TriggerMesh folks, and a bunch of other folks, so there is often, there's abstractions.

13:12 Nic Jackson: There's a lot of great stuff out there. Yeah. CloudEvents, FromTracing and stuff like that. You've got Open Tracing Telemetry, which gives you the necessary interfaces. But at the same time, I think moving from one cloud to another is, again, it's not something that people take lightly. See, I think it's a back to value. Where is the value? And I think you've got to ask yourself that question when you're sizing up piece of work, and ultimately you should be looking for the answer which is, the thing that gives my business an up tick, which could be abstraction. Maybe it is a multi-cloud solution. That could be the thing. But you've got to ask the question, where is the value?

13:44 How important is creating an effective developer workflow?

13:44 Daniel Bryant: Something I learned in my role as an architect is asking the right questions. Looking at the right trade-offs, that is a key thing, because for every rule there's an exception, pretty much. And I think you're saying Nic, depending on what your business prop is and what your skill is of your team are, and your resources, weigh all those things up and then make a decision. That's the key thing in that. Actually, as we were talking there, I was thinking about a couple things I wanted to lead into. Hearing you talk, Mishra, I was thinking about Terraform. When I first learned Terraform, I was like, hang on all the cloud stuff's different, but the workflow is the same.

14:13 Daniel Bryant: I remember, when I learned, I got it and I was teaching my team when I was at OpenCredo working, and they were like, "But all these things are so different." And I was like, "No, no. The magic here is not in the standards for the different clouds. The magic is a consistent workflow." And I think we skirted around it here, but I think it's somewhat the same for the platform. The magic is a consistent workflow, whether you're using Heroku or CloudFoundry. Again, got to be careful with lowest common denominator here, but a consistent workflow for your use case, I'm guessing, you would both think is really important, right?

14:43 Nic Jackson: I think Terraform is a great example on, why don't we have a lowest common denominator of virtual machine? And the answer is it would be incredibly difficult to maintain that level of abstraction across tens and tens and tens of clouds. It would be almost impossible, because the way that those machines work is very different. Some people attach interfaces to machines, some are on NICs, machines are attached to interfaces. It's like you would have to have that deep knowledge and it would be brittle and it wouldn't really add any value, I think. So, I think the key absolutely is in the workflow.

15:19 Anubhav Mishra: Absolutely. And then I think the one thing to note with Terraform is, yeah. Workflow is a big one, but I think the second thing is just a plugin ecosystem and being able to create your own plugin. So, let's say you completely disagree with this stake, that I think I stand with as well, which is really difficult to create the generic VM for three clouds, four clouds, even one cloud to be honest with you, because these primitives move quite quickly. So, you can always write a plugin which pertains to your implementation of whatever those cloud APIs for you are. And that might be on-prem. That might be OpenStack, APIs that you might be using directly, it could be anything. Could be vSphere or anything like that, and you can totally do that. Or you could use another way of bringing things together, which is modules. So, you can bring in things with a library style way, where you have a module for your web server implementation, and that might be on any cloud. It might only expose three or four knobs and that's what really, maybe developer needs, and you're off to the races basically.

16:17 Nic Jackson: I always liked those types of abstractions, Mishra, as well. As an engineer, having those domain specific abstractions in my organization, it just exposes what you need rather than needing to know a huge amount and trying to figure out which dial I've got to turn. I really like those types of things.

16:34 How does the latest HashiCorp open source tool, Waypoint, relate to developer workflows?

16:34 Daniel Bryant: I like you mention, Mishra, of the plugins, as that's something that's not always obviously jumping out to me with Terraform, but it is super strong. And I think you could make the same argument for the value of plugins for the dev workflow. I see, I think it's the Weaveworks team doing the GitOps toolkit. I know HashiCorp have got Waypoint. There seems to be this culmination of ideas at the moment around this workflow is really important. This build, test, deploy, release, get feedback, but we don't all want to do exactly the same thing at every step, so I'd love to hear both your thoughts on the value of a plug-in model if it applies to those steps of a dev workflow.

17:07 Anubhav Mishra: Absolutely. I guess we can talk about Waypoint first. For those of you who are listening Waypoint is something that HashiCorp introduced this year in our annual conference, which was digital this year which is unfortunate. We love to host people. But we announced two new projects and one of them is Waypoint. And the idea here is to give a consistent workflow, which involves building, deploying and releasing across multiple platforms, different clouds, different type of platform. For example, Danny Lee mentioned Heroku and things like that. And also give you some of the tools like validating your deployment, and also the key pillar here is the plugins.

17:44 Daniel Bryant: The idea is to make the plugin development really, really easy. And for you to extend the project for your own needs, for your own platform, for your own environment. And I think that's the premise here. And the plugin model is pretty much what we've learned from Terraform from over the years, which you see the Terraform has a very vibrant provider community, which is basically the plugins. And, yeah. It means in this case, being specific to application deployment here. And Nic is a perfect person to talk about plugin development because he worked a lot on Waypoint on that one particular focus. So, Nic, I'll let you take it.

18:20 Nic Jackson: Yeah. I think it's super important because it's, again, we're talking about the workflow. You've got to give people the ability to define extension. And you mentioned Weave, and I super dig Weave. I think some of the tooling that they've produced specifically around popularization of the concept of GitOps, Flagger, tools like that, I think are incredible. And what we want to do with Waypoint, we don't want to compete with that. What we want to do is be able to allow people to integrate with that. So, it's following that classic tower principle, workflows not technologies, even our own technologies. So, Waypoint has a rich plugin ecosystem which allows you to integrate, say something like Flagger or maybe you want to integrate with Google Container Engine. Maybe you want to do some Lambda or Kubernetes. Or maybe you've got a very bespoke internal system that exists, and you want to do some integration with that. Well you can write your own plugin to integrate with your own system. So, it's fully extensible because what we want to do is help you with the workflow rather than force you down to choosing a section of technology.

19:24 How important is it to focus on observability and security within developer workflows?

19:24 Daniel Bryant: Changing gears a little bit. I'm really curious to dive into things that get ignored often in the workflow. And for me at the moment it's observability and security. Observability is completing the loop for me. I see a lot of folks talk about continuous delivery, there's no mention of actually completing the feedback loop. Looking at your KPIs, looking at SLIs and feedback. And security, it's like, as unfortunately we're seeing in the news throughout this year, it's a big issue for us. And software is everywhere, and I think we hear as professionals, we recognize the responsibility is increasingly falling hard on our shoulders. So, I'd love to hear your thoughts on how developers would benefit from thinking more about security, observability in the workflow.

20:01 Nic Jackson: So, security, I think, for the majority, am I going to make another controversial statement by saying it's not people's primary concern? And the reason that I say that is because security is super important, everybody knows it is, but when you're fighting fires in your application, it's the thing that you can't immediately get at. Now, I think with security as well, that a lot of security should just be done for you. It should be automated as much as possible. You've got tooling which allows you to do scanning, why can't we have systems which just deploy applications and configure the platform in a secure way? And I think we're getting towards that.

20:37 Nic Jackson: Observability is also quite hard. I mean, getting metrics out of a system which maybe doesn't naturally emit metrics is not that easy, but it's incredibly important. So, I think those are the two areas that we really need to get better at automating. I think those are the two things which shouldn't have to think about to a greater extent. It should be something you're aware of, but it should be something that the platform manages for you. I'm not a security expert. I've got an appreciation of what the risks are, but I'm by no means an expert. I really need somebody to help me with these things, and it could be the platform that does that.

21:12 Anubhav Mishra: I think that's why you see the rise in, for example, that it does explain the rise in things like service meshes and stuff like that. They do give you end to end mTLS and things like that. That's why I think what Nic is saying is that, it's not your primary concern. You want the environment that your app is running in to do that for you. And the interesting thing is the more people move to cloud, it's like an entitlement that you almost claim, and you say, I'm running in the cloud. I should be secure since I am running behind all these firewalls and things like that, but that's not always true. We all know that. All the primitives are there though. Like the cloud has all the primitives to do that, so I think the idea is for something to configure it in the right way, so that you can make use of them basically.

21:57 Nic Jackson: And again, just to clarify. We've been here. We've been in a situation where we know that our security, personally speaking, is not optimal, but we've got the question of the application needs to be stable for say Black Friday. Now I can only do one thing. Do I look at fixing security when there is a risk that I might not get hacked or I might not be compromised? Or do I fix the application, when the application I know will go down? So, I think a lot of people are working with trade-offs and choices, and I'm not saying that avoiding security concerns is the right thing to do, it's not. But you've got to make choices. You've got to take balance, and when you don't have unlimited time and unlimited abilities to fix things, more often than not, the risk is lower than other priorities, even though rightly or wrongly.

22:48 Can service mesh help developers with observability and security?

22:48 Daniel Bryant: I hear you, Nic. It's again, as an information technology professional, it is about trade-offs. I think that's the number one thing. I'm being very honest and upfront and documenting and sharing at the right level. Those trade-offs, because sometimes I think that doesn't happen. I've seen that in my career. Some of it does, and the folks still make the wrong decisions, so I'm not saying it's perfect, but it's just recognizing it, I think. And so is really key.

23:07 Nic Jackson: Back at the original one. It's just something we shouldn't have to deal with.

23:10 Daniel Bryant: I like Mishra's mention of Service Mesh, because I'm all in the Service Mesh space these days. I think that security like the mTLS is super interesting. I think also Secret Storage is really important. And initially Nic has already done a shout out for his book, I've got to do a shout out for your book, right?

23:22 Anubhav Mishra: I do have a book coming out. It's a getting started book. Funny enough, I started writing with Nic, and Nic has a lot to do in terms of the early chapters of the book here. So, you'll see some of Nic's writing in my book as well, which is great. I do give him the acknowledgement and he does get the shout out, so don't hate on me.

23:39 Nic Jackson: I apologize for any readers. I'm really looking forward to that. I think it's going to be a great book, Mishra. I think security is so important. I mean, if I was a CTO or a CIO, it would literally be top of my agenda because security is the thing that could absolutely just wipe your business out.

23:56 Daniel Bryant: That's one events type thing isn't it, where overnight it's gone. We're seeing it now, I won't name names but we're seeing it actually as we record a podcast. Folks can look back through the calendar and figure out where that was. But we're seeing these kinds of things, yeah.

24:08 Nic Jackson: Cost of reputation, just the pure financial costs in terms of penalties and regulatory concerns. It's super huge. And this is genuinely one of the things I get excited about Service Mesh. You mentioned Service Mesh and a lot of people groan and I don't know why. Service Mesh, is it just because it's really marketing or really buzzy or is it because the thing that everybody's talking about? But it helps me. I mean, configuring MTLS between services is no mean feat. Locking down the traffic between two services to avoid lateral movement of an attack is not an easy thing to do. Even using things like Kubernetes network policies and stuff. It's not easy. The Service Mesh gives you that for free and it gives you it really easily, with very, very simple policy-based concerns.

24:50 Nic Jackson: So, it handles some of the security that I don't need to think about. And it's a pretty big part of it. Having a vulnerability is one thing, but if you look at any of the attacks which have happened recently, it's not necessarily the vulnerable service which has been the cause of the loss of data or whatever. It's been the ability that the attacker has jumped off from that point deeper into the system. And securing that is difficult, especially in dynamic environments when you've got a lot of moving parts and routing tables can't be static, and machines are changing IP addresses all of the time, and you've got multi-tenancy and multi layers of application networking insides of Kubernetes and stuff like that. Service Mesh really just gives you that for free. If you only use it for that alone, and that's a big deal. And then there's observability, but if you've got another half an hour, I can rant about that as well.

25:41 What will the platform and developer workflow space look like in five years time?

25:41 Daniel Bryant: Awesome stuff. As we're coming up to time there gents, I'd love to give a quick take for the final few minutes of what do you think is going to be super interesting in the space we've talked about today, over the next, say five years? Looking into the crystal ball a little bit as we're approaching the new year or in the new year when the podcast is published, what do you think folks should be looking at or do you think is super interesting? Yeah. Where do you think the developer experience, we're all developers or to some degree here, where do you think that's going to go in say five years' time?

26:09 Nic Jackson: I've been thinking about this a lot, and I think you've got to look at the past. Now you can call me an absolute Luddite, but anybody who's worked with frameworks like Spring, who worked with platforms like PCF back in the day, and think about the developer experience that was given to you then, I think we need to build that type of framework for the developer, the types of platform and bring them towards the way that we're building massively distributed Multi Cloud systems. So, I'd like to see that and I think we'll get that within five years.

26:44 Anubhav Mishra: I hope so. I really hope so. Because I think this has been one of my gripes for the past three years, at least. It's just been so difficult to do software. It used to be so easy. It used to be FTP, my PHP file on the server, and it was not the best but it worked. And live edit things on the production server and then save. And as soon as you hit save, it was online. I think the experience was great. The way we went about it, it's of course completely wrong in today's world. I think we have better tools to do all of those types of things. But I think the experience that the developer got at that point of being able to write something really quickly, maybe fix a production outage or something like that, and being able to go through the step of building and deploying it and releasing it safely.

27:29 Anubhav Mishra: And then what you said, Daniel, which is to grab the logs or the telemetry or being able to observe the application in a consistent way per deployment. Per deployment, that's really important here. I think those are the type of things I want to see from either the frameworks, or some abstraction that someone builds. But I hope we get there fast because the rate at which we are creating new things to do the same job, it's way up there compared to the rate average we are creating good platforms that actually hide some of this complexity from people.

28:00 Nic Jackson: I remember when I first started my career and somebody say, "What do you do?" And I'm like, "Oh, I'm a C# developer. Or I'm a Java developer." These days it's like, "Oh, what do you do?" It's like, "Oh, well I'm a Go developer, but I'm also a Docker expert and I'm pretty dab hand at GitOp actions, and I know a bunch of stuff about configuring Prometheus and writing Grafana queries." And, "Oh, I'm an expert with Kibana logs and Kubernetes? Yeah. I know all about Kubernetes, configuring it and I can do Terraform and I can define clouds. Or a bunch of stuff around Make files. I mean, I know Make inside out and that's just one build system." It's really hard. If you come into this industry now as a graduate developer and it's like, okay, great. You know how to program, you're a great programmer and now go learn this other 500,000 different things.

28:47 Anubhav Mishra: I'm just going to say good luck to them. Just good luck. For me, I don't even explain. It's like, you know what? You're going to find out in the next one hour or so. Good luck to you.

28:56 Daniel Bryant: It's genuinely tricky. One thing I'm very privileged to, and I think we are all the same here, is coming up with CGI, you mentioned PHP, Mishra. I did tell Perl, this kind of stuff. I've literally lived it. I had my first computer when I was 10. So, I think it's a massive privilege. It's much easier for me to build mental models. I've heard Kelsey Hightower talk about this. We all love Kelsey's stuff, but he was often saying, his advice, if you want to know about Envoy, about proxies, learn NGINX, learn about the history, the simplicity, the birth of the tech, because everything good is transferable within the generations. Which is building it. And then when he said that, it was a classic Kelsey pithy tweet, and I was like, you're on point again, Kelsey. I'm going to save that one, because I'm chatting to people I'm mentoring, and I realize they don't have all the context that I've got from 20 plus years of IT experience.

29:42 Nic Jackson: And I said this earlier, but I really think that we do take one step backwards when we move two steps forward. And I think at the moment where we are now, we made two steps forward into getting to distributed systems, but we did take one back around the developer experience and developer workflow.

29:56 Daniel Bryant: One giant leap back.

29:58 Nic Jackson: Seems to take time for the tools to catch up with the patterns and the architectural practices, which I think we're getting there.

30:05 Anubhav Mishra: Someone told me this really early in my career is like, you're going to see the pendulum swing off technology. So, it goes one way, pretty extreme, pretty hard, and then comes back to the same point. And it's so true. I think we've reinvented packaging I don't know how many times. Just like apt to RPM stuff through JAR files to using virtualenv things, isolating in environments like that, containers, and then we are back to files. It's just like, I don't understand where does this stop? Hopefully, eventually, we do concede and say that, okay. This is okay for us for now.

30:42 Nic Jackson: One thing which I think I really have to say, I don't miss. And that is XML.

30:46 Daniel Bryant: As a recovering Java developer I can definitely echo that. When I was doing Spring it was all about the XML. Now I'm doing some Spring boot today, it's annotation driven these days. And I'm like, this is awesome.

30:53 Nic Jackson: Spring have done really well. I'm very impressed with the way that Spring has continued to evolve over the years and everybody's worked well. The trend is Go and maybe Rust and Node and things like that, but there's a lot to be said about a mature language like Java, and a really, really good framework like Spring.

31:12 Daniel Bryant: I'll plus one on that, Nic. On that note, we're coming out to time. Perfect ending I think. We've covered a lot of great stuff here. Really appreciate your time today. Thank you very much.

31:19 Nic Jackson: Thanks very much, Daniel. It's a pleasure.

31:19 Anubhav Mishra: Thanks so much. Thanks for having us, Daniel.

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT