In this special year-end wrap-up podcast Thomas Betts, Wes Reisz, Shane Hastie, Charles Humble, Srini Penchikala, and Daniel Bryant discuss what they have seen in 2021 and speculate a little on what they hope to see in 2022. Topics explored included: hybrid working, the importance of ethics and sustainability within technology, and multi-cloud architectures.
Key Takeaways
- Hybrid working is here to stay. Key questions to ask include: What is the right balance? How much time do we need to be together in person? How is onboarding impacted? Also, how much time do we need to be synchronous in terms of time zones?
- There may be a COVID corollary to Conway's law; companies that have been effective at developing loosely coupled systems (often with a microservices architecture) were better set up to work remotely and using a distributed approach. It's the independent and highly aligned teams and the people that make microservices work.
- There have been three interesting developments in the data engineering and AI/ML space in 2021: data management - ingesting and cleaning data; infrastructure - the rise of data engineering platforms and services based on cloud technologies; and operations - the emergence of "DataOps" and the DevOps complement to data
- Engineers can build amazing things these days. They have access to code generators and ML-based coding assistants, highly scalable cloud computing, and a global reach. However, "with great power comes great responsibility.” It is vitally important that all of us think about things like ethics, diversity and inclusion, and sustainability.
- Any reasonable-sized organization today is multi-cloud. We expect this topic to be a continued focus area in 2022. Important topics in this space include: providing a good developer experience (for example offering a "paved path" platform), considering security and governance early in the SDLC, and being clear of the goals when adopting multiple cloud technologies.
Subscribe on:
Introductions
Daniel Bryant: Hello everyone, and welcome to the InfoQ podcast. I am Daniel Bryant, and it's that time of the year where all of the InfoQ podcasts co-hosts get together and reflect on the past year, discuss important topics in the field of software engineering, and look ahead to the next year. This year, I have the pleasure of being joined by Thomas Betts, Charles Humble, Srini Penchikala, Wes Reisz and Shane Hastie. And without further ado, could everyone please introduce themselves?
Thomas Betts: Hi. Thomas Betts, one of the co-hosts. Happy to be here for the end-of-the-year review. I'm also the lead editor for architecture and design at InfoQ, and I'm a principal architect at Blackbaud.
Wes Reisz: Hi, my name is Wes Reisz, also one of the hosts for the podcast. Just recently chaired the QCon Plus that we had in November. And in my day job I'm platform architect for VMware working on things like cloud, multi-cloud, CI/CD pipelines, stuff like that.
Shane Hastie: I'm Shane Hastie. I am the lead editor of the Culture and Methods on InfoQ and host of the Engineering Culture podcast. My day job, I am the director of community development for ICAgile and author of the #noprojects book.
Charles Humble: I'm Charles Humble. I'm also obviously a co-host of the InfoQ podcast, and I was InfoQ's editor-in-chief for a long time. I'm now editor-in-chief for a cloud native consultancy firm called Container Solutions. And in my spare time, I also write music and play in a band called Twofish. I've been promising an album on this year-end podcast for about three years, and it actually finally came out this year. So shameless plug. It's called At Least a Hundred Fingers. You can find it on any streaming service of your choice. And we're quite proud of it, so yeah, look it up if you're curious. But yeah, shameless plug over.
Srini Penchikala: My name is Srini Penchikala. I am the lead editor for data engineering and the AI/ML community at InfoQ and the host of the AI/ML podcast. I'm looking forward to discussing the trends and innovations happening in the AI/ML space.
Daniel Bryant: And I'm Daniel Bryant, head of developer at Ambassador Labs and news manager here at InfoQ. My background is very much in software development, but increasingly over the past five years, I've tried to bridge the gap between dev and ops. I've done a lot of work in the Kubernetes space and looking at things like developer experience.
Could you share some tips on hybrid working and remote working? [02:25]
Daniel Bryant: I'll start the discussion today by saying it's great to meet virtually, of course. Love hanging out over Zoom and chatting, but we all enjoy really hanging out in person, particularly at the QCon events, meeting you all at London, New York, San Francisco, and further afield. It was always the highlight of my year. The pandemic is sadly impacting many folks from obviously their lives, their work and so forth. I know many of you have been working remotely for many years now. Could you share some tips for the listeners as most likely the next year or so hybrid working, remote working is still very much here to stay?
Shane Hastie: One of the things that we are certainly seeing in the impact of the shift to remote and now the shift to quote, unquote hybrid is that these are fundamental changes that we are not going to go back from. We're never going to be back to five days a week, three-hour daily commutes and all of that. Most of the people in the software space don't need to spend every day in an office in order to be productive. And getting hybrid right is going to be hard. What is the right balance? How much time do we need to be together in person? Also, how much time do we need to be synchronous in terms of time zones?
A number of the guests on the culture podcast this year, we've looked at organizations that are deliberately going completely, not just remote, but asynchronous, so they can have true follow-the-sun where they barely ever talk to each other like we are now, synchronously. They do it either through short video clips or using tools like Slack, and the shift into how we document in that space becomes really, really important.
So there's a culture shift. There's a philosophy shift. There's a mindset shift. And I think we've still got a lot of learning to do to get these things right. We're seeing these experiments, some of them working, some of them failing catastrophically. And that's okay because we can learn from that, and we can adapt, but that's going to be the biggest, I think, long-term impact.
It also, in my mind, hits things like we are seeing. We are in the midst of the quote, unquote great resignation at the moment. And we are seeing lots of people moving organizations, people caring or recognizing that their personal well-being, their family's well-being really matters and going to organizations who see that. So this touches on the developer and the overall employee experience. Organizations are coming to the realization that if we want to get great people, we'd better have a great place to work. And what that great place to work means will be different for different people.
Daniel Bryant: Yeah, well said, Shane.
Shane Hastie: And the other one I'd like to throw in there, that is we are seeing some movement, but we are also seeing some steps back as well through this, is diversity and inclusion. There are some conscious and deliberate steps forward, but the studies are telling us that, for instance, the impact on women through COVID has been significantly higher than it has been on men. So how do we fix all of these imbalances?
Diversity, ethics, and sustainability have been key themes this year. Can you share your thoughts on them? [05:42]
Daniel Bryant: Difficult question to start the podcast with, Shane, but a good question to ask. I know all of us are passionate about thinking around diversity, ethics, sustainability is key. Anyone else got any thoughts they want to share on those topics?
Thomas Betts: Well, if I can touch on the last thing, my company, when they switched to we're going to go to remote first as opposed to everyone has to move to the headquarters or near an office, we actually saw our diversity increase because we weren't only recruiting people who were willing to live in those places. It really opened up. And I guess we had a year off from our internship program, but the last round was more diverse because we did a remote internship program. So we didn't just get the college students who were within the neighborhood. So you're seeing that younger side of developers. I fully agree with you that the impact on women has been harder than men. That's without a doubt, but it'll be interesting to see how this shows up a generation from now or 10 years from now.
Wes Reisz: At the last QCon Plus that we just ran in November, we actually ran a track, a whole track, called Managing the Return. I think there's some really interesting stories and creative ways that people are making sure that, as you have this hybrid culture which you talk about, Shane, that it's not a culture of have and have-nots, that we're having to be very intentional about making sure that everyone's the same. They have equal access to information, that the water coolers are virtual, that you're able to share information.
There was one story I remember, and I won't mention names because I don't know if I should, but at Netflix they have people that are remote and people that are in the office. So they have leaders that are specifically assigned or have a role that is to be remote, to make sure that they understand that they're feeling and interacting with the information the same way that developers are. It's not just the developers are remote and the managers are in the office. They're actually being intentional about making sure that that experience is the same. I think strategies like that are going to be really important as we go forward.
Shane Hastie: Yeah. The intentionality there is what's going to be really important.
Thomas Betts: I think you said there's a spectrum of synchronousness from, we're going to have everything completely remote, no one talks to each other, to we're going to have everyone in the office, that's the only way things get done. And we've seen trends over the years and software swing that pendulum from one extreme to the other, and I think this is one that we're going to find the happy medium. That's why we talk about the hybrid environment. And you have to find that balance because yes, having asynchronous for documentation and software is great, but you lose the humanity. The computers don't care about the humanity, but the people do care about that synchronous connection.
Daniel Bryant: Well said, Thomas. Well said.
Charles Humble: I think onboarding practices and that sort of thing really matter there as well, that where you have a network of people already, remote working tends to work quite well. But when you are joining a new organization, and I suspect it's also true if you are a junior developer or a junior member of a team and you don't know who anybody is, then that becomes much, much harder. And again, there are ways around this. So I think there are ways around this. I'm not sure we know what they all are yet, but I think it's all very well for I think all of us on the podcast have been in the industry a long time, and we have a pretty extensive network of people and we know our way around.
But I think for junior devs starting out, it's much, much harder and thinking about ways that you can do mentoring, ways that you can do paired programming, all of those kind of things, if you're in a remote-only environment is going to be super, super important. And helping people to get established, to build networks, to make connections.
And I do agree with something I think that Wes was saying, that having some people who are remote and some people are in an office, you can very easily end up with this office clique and a remote clique or just an office clique or whatever and different groups not talking to each other. And again, thinking about your organizational design and making real efforts to overcome that, again, I think is going to be super important as we move into this new working world.
Wes Reisz: That's a really good point to talk about the seniority. Once you have that network and you go remote, it's easier. You already have the context, you already have the connection, but when you join a company (for example, in the middle of a pandemic) that intentionality that we were talking about is critical. And it's just not something that juniors necessarily know innately if we don't just get out there and tell them. That's a very, very good point, Charles.
Daniel Bryant: Yeah, definitely is. Srini, do you have something to say there as well?
Srini Penchikala: Yeah, Daniel. I was thinking more about this from a different perspective, taking a reflection point on what we've been up to for the last almost two years with the COVID. So I think of some analogy of software systems into the discussion. I feel like, as a world, as a single nation, we have all been in a big chaos engineering project as part of this. So each COVID variant is like a new experiment. And other than the lives lost and the other losses we've had, definitely we have all become more resilient to these kind of challenges. So if I have to pick a couple of words to summarize, I would say “Great Resiliency” is one of the byproducts of this experiment. So to align with the great resignation and I say great resiliency.
What has been interesting over the last year in the field of architecture? [10:24]
Daniel Bryant: Good choice of words there, Srini. And that leads nicely for another topic. We've heard about async communication, asynchronous communication, chaos engineering there. I'm thinking architecture, and I'm looking your way here, Thomas, as the author of the Architecture Trend Reports. What's been interesting over the last year or so with architecture, with the fact we can't all gather on a whiteboard, right?
Thomas Betts: Right. I keep thinking that there's a term like the COVID corollary to Conway's law, that the companies that have been really good at developing microservices were set up to just send everybody home and work remotely because it didn't depend on them being in person. And the companies that can't develop a microservice architecture and everything else that goes with it, because it's not the software that's hard. It's the teams and the people that make microservices work.
So if you had to have everybody in the room around a whiteboard to get anything done, you probably weren't ready to do microservices. And so I think this came up in our trends report back in March or April, but we're still seeing the companies that are swinging that pendulum, trying to find what's the right balance between we had a monolith and it didn't work because of what reasons, and we chose a microservice architecture, and it didn't solve all those problems because we didn't actually implement it for the right reasons, or we weren't set up and didn't take care of a paved road and everything else you need for that.
So companies are still trying to find what's the right size? What's the Goldilocks scenario for our architecture? The guests we had on a couple weeks ago talking about architecture, the hard parts, Neal Ford and Mark Richards, said it's the stuff you can't Google. There is no one-size-fits-all architecture. So people think this isn't working for me. I'm going to go to microservices without understanding no, you need to decide. It depends. What does it depend on? What's your situation? What's the right size?
I think in some ways the pandemic, because of the nature of distributing the teams, making people think differently about how they communicate, changes how they develop the software, because I am communicating asynchronously with those teams. Have I gotten better at developing asynchronous software?
Wes Reisz: I love that. That's a really, really great point. I don't know if I've ever put the connection together like that, but I really like that.
Thomas Betts: And one of the other things that came up, I hosted the API Architecture Track at QCon Plus, and asynchronous communications, again, is very important. And I think we're finally seeing async API getting to that maturity point that people are starting to adapt. Just the number of different generators and tools and everything that's been built on that platform has really grown in the last year. I think there were three or four tools on their list at the beginning of the year, and there's now well over a dozen or two.
I think they hit version two this year. I think they've got version three planned, already scheduled, and you're going to see it the way open API matured a few years ago, and people started using that as part of their process to generate code, document their APIs, communicate with each other, so that all those teams that are developing services, they now have one common way to interact with each other. We're going to see that for event-driven architectures as well.
What does everyone think of the topic of “data mesh”? [13:07]
Daniel Bryant: Very nice. Talking of event-driven architectures, I think that leads nicely into the topic of data mesh, which we've seen a lot of InfoQ articles around these topics or rate topics. We've seen coupon talks and so forth. I think it nicely leads into some of the AI and ML and data engineering topics as well. I've got a hat tip to Zhamak Dehghani every time I mention data mesh. She's one of the founders, right. She is awesome and has done lots of fantastic talks. But I'd love to get people's thoughts on, is this microservices in data form? What's driving the trends with data mesh?
Thomas Betts: I think next year, I know we're doing the end of the year, I'm looking forward to what's in 2022, I want to see data mesh start getting it adopted and seeing more of those stories written of here's how we implemented it. Here's how we structured our teams around it. Because it really is that idea of domain-driven design. You have your small teams, your bounded context, and that's what controls your data. You produce your data products in the same way.
And so if we've aligned our teams to say the data is just one more product that I produce out of my team, it's not just my API or my SPA or whatever I'm writing, but I have this portion of the data getting away from, again, the monolith of data architecture that you had. Everybody goes into one giant ETL data warehouse or data lake, and it turns into the data swamp because nobody can find anything they want.
Data mesh is we're going to have governance, we're going to have patterns so that people can find what they're looking for, and then build on top of that. And then probably another year or two down the road, when this matures, you're going to see the next level of people have built stuff on the data mesh because it's allowed them to move faster.
Srini Penchikala: I agree with that, Thomas. Data mesh is more than just an architecture. It brings the governance and domain-driven design principles, the rightly-sized team members and everything. So yeah, definitely, I'd say it's a unified approach to bring data into the whole architecture.
What is interesting currently in the AI and ML space? [14:51]
Daniel Bryant: On that note, Srini, what else is interesting in the AI and ML space? So something that was floated earlier in our off-mic discussions was things like machine learning with coding, things like GitHub Copilot. There's a whole bunch of ethical questions we can definitely explore in a moment, but I'd love to get your thoughts around the general ML space for that.
Srini Penchikala: Yeah, definitely, Daniel. I've been thinking about this myself. It's almost like, what's not happening in AI/ML space? I looked at all the different articles we published and podcasts we posted this year, and at a high level, I tried to group these topics into a few categories to just make some sense of what's all happening. I came up with four high-level categories. I don't know if you guys agree with this, but just to put all this into perspective.
So mainly, I want call this data management category is the first one. That's where you get the data from either IoT devices or now we are talking about autonomous vehicles. Streaming is the main trend here, that data being generated every second, every so frequently. So data management includes the data ingestion, data storage, data processing, data integration using GraphQL or other API-based data access solutions. And then also obviously data processing and analytics. So it's a broad term for that, and there's a lot of innovation happening in this area. We can talk more about this later in the podcast.
And then outside the data management, I want to call the second category infrastructure. This is where data area has caught up with the API and other parts of the architecture, where we are now leveraging the containers to run Spark jobs, using Kubernetes to scale up and down as demand requires for machine learning solutions. So infrastructure is playing a big role here, and we even have GPU-based solutions that a lot of companies are using and other innovations happening in the infrastructure as well.
And then the third category is the operations. This is, again, one of the areas that the data space has been lagging behind compared to the development and architecture areas, but now it has caught up as well. So we have a DevOps-based approach on the data side called Data Ops. How can we make our databases reproducible, easy to create, easy to version, easy to repeat? Not like how one monolithic database that when that goes down, the whole company is not operational kind of thing. So a lot of those things are changing thanks to Data Ops.
And now we also have ML Ops. How do we bring the same best practices into machine learning space? Typically, if you look at machine learning life cycle, you have the models and you have the training data and the test data, and you can iterate through the data to find out which model is going to work for you. And then you deploy the model to production. So if we do it all manually, it's not going to sustain the needs of the business users. So ML Ops makes a lot of those steps in the process more automated, using Feature Stores to version the machine learning models and be able to dynamically apply those models. So that's the third area.
And the final one is basically the ethics. I know we are going to spend a lot of time on this later in the podcast. This is how we can use AI and ML solutions, or data engineering solutions in general, with the responsibility and fairness in mind. How can we make these solutions equally fair to all the different demographics and different users?
What do you think about coding assistance tools like GitHub co-pilot? [17:45]
Daniel Bryant: Very nice, Srini. I'd like to get a bit of discussion going actually as a precursor to that. What do folks think of things like GitHub Copilot? Do we think listen to the podcast? Are they going to be out of a job next year when the machines take over and start doing all the coding? Is that ethically valid? From many aspects, I'd love to get all of your thoughts, your discussion perhaps on this.
Wes Reisz: I don't think we're going to see true artificial general intelligence anytime soon, machines that are going to think and do all the things. But I think we are seeing and continue to see AI being able to augment what humans do. Just think of cruise control in your car. We've all used cruise control a bit, and it maintains speed. Now it nudges you a little bit, all the way up to full self-driving. And I think of that when I think of about things like GitHub Copilot, because it's not replacing the developer. It is not artificial general developer intelligence. It's helping you with the boiler plate that we've been complaining about for 20 years. In my opinion, I think that's the right way to think about Copilot.
Thomas Betts: And I think it's the next natural evolution of making it easier to write code. You had to write Assembler, and then you had a compiler. And you're like, "Oh, you can't write code that has to go through a compiler, because it's not as fast as the native." And now it's like, "Oh, I'm so many layers removed from writing the Assembler, it doesn't matter. I am more productive even if my code is slightly less fast. It doesn't matter." And so it solves those problems that I don't want to solve.
I think it's going to be closer to that low-code, no-code space, that this is the stuff that it doesn't take someone with lots of experience in software engineering to solve that can help other people get up to speed. And maybe it'll help more people get in or solve small problems.
Wes Reisz: Do you think it's more like low code, no code or more like serverless where you're just focused on the logic, not necessarily the ceremony?
Thomas Betts: Maybe that's a better analogy, but I still feel like it's solving the problems that I can just put it into a box and ignore it. And so that's just my generated code over there, and I don't think about it anymore. Because one step away from that is I don't even have to start describing what I need. It's able to figure it out. And that's when we get to the, oh, now it's going to replace my job because the business analyst just talked out loud into a microphone, and the software spit out. And I don't think for anywhere close to that.
Shane Hastie: That works on the assumption the business analyst knows what they need.
Charles Humble: I agree with all of that. I think it basically gets rid of the easy bits, if you will. The hard bit about software is figuring out what it is you're trying to build, and none of these tools really help with that. I think that's the same problem with low-code as it goes. Yes, it allows people in the business who are not developers to build systems up to a point, and that's great up to a point. But again, that's not really the hard bit.
The hard bit is working out how to build the right thing and how to build it in a way that works and is repeatable and all of that. And a lot of low-code solutions break down that. I don't have a problem with them. I'm not against them. I actually think they can be quite a useful way in. I know people, really, really great developers, who cut their teeth in Visual Basic or Microsoft Access back in the day or whatever it was, and started learning there and then gradually moved into more what we would consider pre-development environment. So I don't have a problem with it at all. I think it's all for the good, but I don't think any of us are going to be out of a job as programmers anytime soon. I really don't.
Wes Reisz: One of my favorite quotes, and I know, Charles, I've said it before with you and I talking on the podcast. But it's Grady Booch talking about software is the art of working at higher and higher levels of abstraction. This is a higher level of abstraction.
Charles Humble: Wes his keynote, Grady's keynote from QCon New York, I think, three or four years ago is just a wonderful, wonderful talk that everyone who's listening to this should go and watch.
Wes Reisz: It was San Francisco, and I agree. It was one of my favorite ones. Grady Booch has been part of my entire software journey at some point, reading books and reading posts and watching videos and repeating that quote over and over again. I know it was a high moment for me too. That's a great call out, Charles.
Shane Hastie: What are the ethical implications? What are the implications on education and training? What are we requiring of the people who are coming into the industry? When I started coding, I did Assembler and looked down on those who couldn't. That's not appropriate today, but is it useful to have an understanding of the bare metal architecture and how the code that you've been doing impacts on that? But also is it useful to have an understanding of the people, the culture and the environment and how the code that we are producing impacts on that?
So this is something where we've got a whole lot of challenges as a society that we are not tackling yet. We're using 10% of global power. We have a bigger impact on the environment than the aviation industry. How are we tackling that? We know that we can, and AI and ML is giving us some opportunities to do that better, but there's also Bitcoin mining, which is sucking up so much of the global resources and so on and so forth. There's a whole can of worms here.
Wes Reisz: It's interesting you bring that up because I think that goes back to that higher and higher levels of abstraction, because we're gaining more and more ability to do literally with a credit card and AWS, maybe some code generated from GitHub Copilot, we can do amazing things and have a worldwide reach in literally minutes, if not hours. It's amazing what we can do. And I think that you talked about ethics, Shane, and I think that too long software developers' only ethic training was Star Wars quotes, which is “With great power comes great responsibility.” That's not enough. We need more to be able to do some of the stuff we're doing, because we have amazing power with the AI and the reach.
Shane Hastie: Moving fast and breaking things is dangerous.
Charles Humble: I do agree with this. We're just starting to see ethics courses in computer science degrees in the states and in Europe, but that's really quite new, which is, I think, shocking. There was no ethics element when I did my computer training at all. It wasn't even really a consideration, and I suspect that's true for a lot of us. And yeah, we do. The systems that we build can have profound impacts on people's lives, and we don't talk about it enough, and we don't reason about it enough, and it's really scary.
If you are building models to determine whether somebody should be let out of prison or building models to determine whether someone should get a credit card, all of these things can have profound impacts on people's lives. And we just don't think about them at all. And I do think that's terrifying.
Shane, you also touched on the environmental side of things. So I joined my first environmental protest movement when I was 16 years old. I will be 50 next year. And it feels to me like literally nothing has changed in the intervening, whatever that is, 34 years, or very little has changed. We are, I think, as an industry, finally starting to talk about it, which is something. There are lots of green organizations, the Green Software Foundation and various others, that are popping up and starting to try and apply pressure. But it does feel like real baby steps.
And bluntly, I think the problem needs more attention than this. I think that we tend to focus a lot on what individual developers can do, but I actually think this is mainly a problem for the big cloud providers. So I think to shift your code to the cloud, and then demand that all of the energy that your cloud provider is using is green would be a really, really good start, because it seems to me that's going to have more bang for your buck than anything else.
There are things you can do to help like demand shaping, so basically moving where your code runs around the globe according to where the energy is greenest at that particular time of day or whatever it is. Thinking about whether you can batch stuff and run them when the sun is shining and more of the electricity that you're using is coming off solar panels, all those kind of things. We talked about this a bit with Asim Hussain on the InfoQ podcast. So that's worth checking out. But I don't honestly think rewriting all of your code in assembly language or something to make it more efficient is going to have that much impact. It'd be lovely to think that it would. Our old assembly code is like me and Shane. We'd suddenly have a new lease of life.
But in truth, I don't think that's where the answers are. I think the answers are more in basically putting pressure on the cloud providers who in turn can put pressure on the electricity providers to shift. Bluntly, this is a simple problem. Really software people have no excuse, as far as I can see. If you are making hardware, it's harder. The carbon that's used to make the servers that our stuff runs on, that's a much harder problem to solve than the software side. But really software, we just need to go on and get it sorted, it seems to me. I know that probably sounds terribly naive, but just get on with it, for goodness sake.
Wes Reisz: I would push it even as far as to say that sustainability and ethics is probably the largest problem we face as software developers. The technology is going to change. I think it's something that we've really got to solve. Look at some of the people that have been amazing speakers at QCon over the last few years, people like Adrian Cockroft, Eugene Kirpichov, Astrid Atkinson.
Astrid just did a talk [at QCon Plus]. She left Google working in the SRE space to start Camus Energy, to be able to start focusing on some of these problems. When she did her introduction, she said, "People ask me why I quit Google." And she put up on the screen, a picture of her son. She said, "In 2050, he's going to be 37. I want to do things that's going to make the world a better place for him." I truly think it's just amazing to see some of these great minds that are not necessarily leaving software, but moving software to focus on this problem because I think it's that big of an issue we should be dealing with.
What are the current challenges with storing data on people? [27:24]
Daniel Bryant: Talking about sustainability and ethics, what about the massive amounts of data that are now being stored and processed?
Shane Hastie: I'd love to just throw in a question around data sovereignty with big data and cloud today. Who owns that data and where does it live?
Daniel Bryant: That's a great question, isn't it?
Srini Penchikala: It depends.
Shane Hastie: How frequently do we ask ourselves that question?
Thomas Betts: I don't think there's a single answer to that.
Wes Reisz: It depends.
Shane Hastie: As an industry, as individuals, when we are building these data lakes, these data swamps, what is the ethical and culturally appropriate ownership of data or sovereignty of data? I live in New Zealand. We are seeing a lot of work going in here at the moment in data sovereignty for our Maori population. It's not just yours. And if we are, pick your large organization sucking up lots of data about us, what should they be paying us for this, among other things?
Daniel Bryant: Very interesting. We are seeing a lot in Europe around GDPR. We have done for a number of years, and there's obviously CCPA and a bunch of other similar initiatives. And I think that's at least some of the conversations I'm having with customers that is forcing people to think about these issues. I'm not saying there's a solution coming up yet, but I think the first part of a problem is recognizing it's a problem. And I think GDPI has been a big change in Europe.
Wes Reisz: I think GDPR was very different in a lot of cases with regulation, because it forced us to think about things where there definitely wasn't necessarily a solution to some of the problems they were saying you needed to address. So I think it really forced us to get ahead. Usually legislation is so far behind that you're just implementing something that's already way in the past. But I think GDPR was a little different in the respect it really forced us to think about things that maybe we hadn't solved.
Srini Penchikala: I agree with you guys definitely. I think the data, a lot of the organizations have been implementing these regulatory compliance type of practices, but they have been doing those because they have to do it, like banks and other organizations. But now, Shane, to your point, data is getting more attention in terms of what's best for the consumer. How do we secure privacy? Who should own the data? I feel with the social media companies have basically sucked that data up every second on everything we do in our daily lives.
Daniel Bryant: I know Tim Burners-Lee, creator of the worldwide web, is looking at this topic too. And I think he's pitching something called data pods where people are personally in control of how their data is owned and used, which is super interesting.
Thomas Betts: I think that personal data mesh idea.
Daniel Bryant: Personal data mesh.
Thomas Betts: Maybe that's where it's going to go. I do want to go back to the question about training for ethics, because I think some of these questions we're talking about, to answer those questions, people are just put on the spot. And you have to react to GDPR, and so now you have to change how you write software. But if we start training software engineers up front to say, "Here are some of the ways you have to start thinking about ethics." Because I think if I had gone through and gotten a CS degree, when I went through school, I probably wouldn't have had ethics. But I have an engineering degree, and every engineering student had to take an ethics class.
And I've talked to people who, let's say they don't remember the '80s like I do. They also had to take ethics classes, or once every 10 weeks they had a lesson on ethics in software because it was starting to creep into their studies. So I think, as we're seeing software engineering get taught more than just computer science, engineering is closer to that professional discipline. You have responsibilities.
If I was going to get my professional engineering start to and sign off, I certify this design, it says, "I understand the ethical implications. If this bridge falls down, I'm on the hook for it." I'm going to take a few extra seconds to review everything. We ought to start thinking about software the same way. If I write this code wrong, is it just going to be biased to a certain population, or is someone going to die because the drug that's administered gets too many doses out? So there's a lot of concerns. I think if we start training people to think about ethics early on, they're just going to come out and start thinking about that in everything they do.
Wes Reisz: I think it's even more though, because we've had ethics, as you rightly state. It's been around, but we haven't had ethics with the type of software that we're writing today. We haven't really thought about the reach. We haven't thought about these ML models that could possibly say where resources are going that could be negative. So I really think we need ethics today focused on what we're doing in software today because it's not just train goes left and some people die types of questions.
Srini Penchikala: Yeah, definitely. I think that is the new "ility" that we want to add to our architecture and solutions. So in addition to security, performance and scalability, let's make sure that the solutions are the right solutions for our customers.
Wes Reisz: Let's coin ethic-ability. We need an ility with ethics in it.
Shane Hastie: Just plain ethical.
Charles Humble: So Thomas, you were talking about engineering as a discipline and the fact you needed professional certification to be an engineer or a civil engineer, and that was have an ethical component. And there sort of is, but there kind of isn't the equivalent for being a professional computer programmer. But I actually wonder if there should be. I wonder if we are building systems of a planetary scale that can have real impact, then whether we ought to have to do some sort of certification to say, in essence, we know what we're doing.
Thomas Betts: And I feel like it's one of those cases where it would be better as an industry if we got out in front, and we came up with the governing board, the standards bonding, whatever it is, as software engineers to say, "This is our profession. We value it. We understand the impact we can have and what can go wrong if our software fails." To come up with that rather than waiting for something bad happens, and then it gets regulated by people who don't understand the industry. If the government writes the regulation of how to be a software professional, it's not going to be good for anybody.
Charles Humble: Absolutely. Two things though. First of all, you're right that governments tend to only legislate in response to a disaster for the most part, and also they don't understand the field for the most part. So I agree 100%. I think it's really, really important as an industry that we try and get ahead of this, because if we don't, then we'll end up with waves of badly-written, badly-conceived regulation that's trying to control what we do, I think.
Wes Reisz: I can envision someone out there listening, agreeing that if we don't regulate, something major will happen, and we'll be regulated. I can see people nodding that, but I can also see people out there going, we're software developers. We have a culture of, like Shane said a minute ago, move fast and break things. We learn, and we have young kids producing code at times. This is our culture. This is who we are. We're not professional engineers that get the certification before we're allowed to be able to write a serverless function. We have no-code, low-code solutions. So I hear you, but I don't see it. So how do we bring these two together between yes, we need to self-regulate but yeah, we're working at higher and higher levels of abstraction?
Shane Hastie: And if we go back in history, engineers didn't used to have regulation. They didn't need ethical training, and the reason that it came in is because bad things happened. Bridges fell down. Bad things have happened as a result of software. And I think there is two levels of stuff. There is the software that is not life and safety critical. But if you are working in the realm of products that, if something goes wrong, have significant impact on people's lives, livelihood, and existence, then we should have, as an industry, some entry criteria, at the very least some education.
Shane Hastie: I've been working on coming up with a code of ethical conduct for Agile coaching, as part of an Agile alliance initiative. And one of the best contributors to our group was a lady who teaches ethics to seven-year-olds because she raised simple questions about what is right and what is good. And it's time that, as an industry, we started asking those hard questions. What is right and what is good?
Wes Reisz: I think that's a case where GDPR is getting it right. I'll give an example. There weren't really good solutions for how we can document and instrument some ML models. They exist, but GDPR said, "You must have provable ways that you came up with this particular model." GDPR said, "You have to do this." We had to go in and think about these problems. They were hard problems. But I think in this case, while I'm not necessarily a proponent for the regulation, they came out and said, "Look, if you don't solve this, we will, and we're going to impose certain financial obligations," which made companies react. And I think that's a good thing. I definitely wish we could do it ourselves without that happening, but that's the reality of what it is.
Shane Hastie: And there are professional bodies. There's the Association of Computing Machinery, the ACM, the IEEE Computer Society. They actually have codes of conduct. They have codes of ethics, but how many software engineers today belong to the IEEE?
What has been interesting in 2021 in the topic of cloud computing? [36:15]
Daniel Bryant: So let's change gears a bit and look at the important topic of cloud computing. This space continues to see massive growth. Wes, I know you've been looking at this.
Wes Reisz: Just this morning, I was looking to see what the size of the cloud market was. Does anybody have a guess? What's the size of the cloud market in 2021? Any wild guesses?
Thomas Betts: You're talking dollars or computers or bits?
Wes Reisz: Pick your currency. I'm afraid to say what. Well, $90 billion (in US dollars). The cloud's not getting any smaller. It's a massive thing. I think obviously there's tons of services that we could talk about. But what I personally think is that multi-cloud, hate it, yell about it, scream about it, say it doesn't exist, say you'll never have it. Companies buy other companies. Companies merge. You're going to have multi-cloud. It's a reality whether you like it or not. I'm sorry. Never mind. But it exists. It's a reality. So you're going to have to come to terms with it.
And not just multi-cloud. I think hybrid cloud too, in particular. Yes, I work for VMware. So we'll get that out of the way now. Full disclosure. I work for VMware, but I absolutely believe multi-cloud, hybrid clouds are part of our strategies. And while you may have just a singular need at the moment, or even be able to keep that for a long period of time, it's a reality of what we have to face. And I think that's one of the big things that we saw a little bit last year, and we'll see more going into 2020. Daniel, this is your space too. What do you think?
Daniel Bryant: Yeah, 100%, Wes. Any reasonable size company I chat to at my day job has multiple clouds, either because there's different clouds do different things, different ways, better, cheaper, and a lot through M&A. When they merge with companies or companies get acquired, suddenly you're multi-cloud. Surprise. And you've got to deal with it. So it's a tricky one. And I think we are seeing some technical solutions to the problem now, things like Anthos from GCP. We're seeing AWS with Outpost and a bunch of other things. Every cloud provider has got their flavor of it.
And I think, for me, the interesting thing is going to be the control planes working with all these clouds. I think the reality is everyone's going to be multi-cloud, hybrid cloud. It's how do we best interact with these things? And a few of us mentioned it. Things like governance are critical. And security, in particular. How do you authenticate? How do you authorize consistently across platforms? Both from an engineer perspective and also from a user perspective. So I think the multi-cloud is going to be a big area of development over the next few years.
Wes Reisz: Yeah. And also how you manage, particularly in the Kubernetes space. When you have multi-clouds or Kubernetes clusters, how do you have policy in a common way across them? How do you bring them to a single control plane? I'm not talking about tens or dozens of clusters. When you have hundreds, if not thousands of clusters, how do you think of these things logically, bringing all those things together and, again, work at a higher level of abstraction so that you can deal with these different constructs?
Thomas Betts: You see this with services and development. You have the paved road, like this is the way we make it easy. So most companies, I think, that do have the multi-cloud, we'll say, "Here is our preferred route. We're going to make it easier to develop on Azure or AWS or whatever it is because we've done the extra effort." But just like you can choose Java over C#, use what you need to do your thing.
And if there is a small piece, hey, there is an AWS product that just solves my need perfectly and I can justify it, can you hook it in? Give you the ability to use the right tools for the job, but also make the decisions. I'm not just going to it because I don't know about anything else that's out there. And we talked about this in the Architecture Trends Report too, Daniel, that the multi-cloud isn't usually a design decision.
It isn't something that people say, "I'm going to design so that I can quickly flip a switch and move from AWS to Azure." And we're just going to decide one day to move everything over. It was the same justification of, oh, I want to have this abstract data layer so that I can suddenly switch from SQL server to Oracle tomorrow if I ever make that decision.
Thomas Betts: Nobody does that. And when they do, they take months or years to make the switch. So if you have to get off of one cloud provider onto another because you had that acquisition and it doesn't make sense to have two bills, fine. But if it's just an accounting headache, then leave it as an accounting headache to pay two bills.
Srini Penchikala: I think this is where the good old architecture practices like Cloud Native patterns, that's what they call them now, they have started from the Gang of Four design patterns and the domain-driven design principles. So this is where I think those can help the developers. So if we make our applications Cloud Native and agnostic to the providers, they should be able to easily deploy to any of these cloud providers. And also I agree with you we need some kind of federated model to replicate the policies across the clusters so logically they look like a single control plane.
Wes Reisz: A big problem in multi-cloud, Srini that I hear about a lot and I'm curious to get your take on (sorry, I'm surprising this on you), but is around data gravity. In a multi-cloud environment, how are people thinking about where the data lives is? I mean, where your data is tends to be where you put your infrastructure to support it.
Srini Penchikala: Yeah, definitely from my observations I look at the data and API along with the integration layer. So the integration layer is the very important aspect of the architecture. You have the data layer including the data ingestion, storage and so on. And the API layer is there for the applications to get the data from the data stores. This integration layer where you can use the messaging technologies, that's where you can apply some of these policies. Whether you want to secure access to a database or whether you want to authenticate a user to make sure that he or she is authorized to perform that business function. We can do some of those in a common way in this integration layer.
So that's definitely getting a lot of attention. So that's becoming part of the Cloud Native technology, and that's where the whole Async API and event-driven architectures that Thomas mentioned earlier are also getting more attention now.
Daniel Bryant: I'm going to shout out Wes. He did a podcast with the OPA folks, the Open Policy Agent folks, and that was super interesting. And two things I see bump up a lot in my space is OPA, Open Policy Agent, and Crossplane by the Upbound folks as well. And they're both really looking at paved roads, where Crossplane is more paved road for the platform level, like Thomas mentioned. And I think OPA, looking to that paved road when it comes to authentication authorization, having that common standard across these massive fleets.
Wes Reisz: Yeah, absolutely. OPA is definitely a powerful tool. That was a fun podcast to do.
What is the current state and future of managing software supply chains? [42:19]
Daniel Bryant: Nice. One thought that we haven't covered too much that is related to this is the software supply chain. Obviously now we're pulling in dependencies, be it libraries, be it cloud services. It comes back to the ethics topic again. How do we take ownership, responsibility? Something Charles and I were discussing earlier. How do you get visibility into some of these things? I'd love to get your thoughts on software supply chains.
Srini Penchikala: One of the areas that I've been paying more attention to recently is the observability. How can we capture the metrics and instrumentation data from whether it's a microservice or a database or a messaging server? So how do we capture the data and correlate to make sure that we troubleshoot the issues and also we identify any slow bottlenecks in the system. So can we add ethics dimension to that space and maybe have an ethical observability type of solution that will actually look at the data and see, hey, we can use this data for making our systems faster and more secure, but also can we make our systems more ethical as well? It's just a thought right now. I don't know what's happening in this space, but we already have the data, so why can't we see if we can learn from it and make our solutions more fair and ethical?
Charles Humble: I think with security though is a real problem, which is it's super, super hard to know the providence of the software that you are running and even, to some degree, the hardware that you're running it on. And as an industry we're being pretty poor about this. I don't think we have particularly good answers yet. There are one or two tools. There are things like in in-toto and Notary and those kind of things kicking around. But ultimately for any component that you are running in production, you want to know that it's what you think it is. And that's very, very hard to establish at the moment, particularly if you're operating at any kind of scale. Unless you build everything yourself, it's really, really difficult.
I think we are going to see a lot more supply chain attacks. And I think whether that's through injections when the software is being compiled or through distribution or updates or however it is, I think we're going to see lots of crypto ransom type attacks and those kind of things happening. And I don't really know what the answer to any of that is, if I'm honest.
As I say, there are some bits and pieces of tooling coming out, but we need some way of saying, "I need to be able to verify that this piece of software is what I think it is." And we don't have a particular mechanism for doing that, as far as I'm aware at this point in time. And I think possibly there are problems in the way the security industry is incentivized, which makes solving that really, really hard. Not technically hard, but politically hard. I don't know if anyone else has thoughts, but it seems to me just a super difficult problem.
Thomas Betts: It's definitely a super difficult problem, but it's one that we haven't really been paying enough attention to. Paying attention to it is the first step at all. Like the solar winds hack, for example, that comes up, and that obviously was sealed code. I think that's what you're referring to, and that's not a solved problem by any means. But in a lot of cases just downloading something from Docker Hub and putting it in your Kubernetes cluster, that's not a great plan. Paying attention to our supply chain, the chain of custody for all the things that go into your production environment, that's important to be able to do. So paying attention to that, I think, is crucial and important.
I can't think of 2021 and not think about the colonial pipeline hack. So I think it's more than just software supply chain. Security, in general, I think with some of the ransomware hacks. I think in that particular one, it came down to they weren't using two-factor authentication and multi-factor authentication. I think that's what was said, at least.
Srini Penchikala: It's going to happen. With all this virtual work models, it's only a matter of time before everything gets attacked.
Wes Reisz: But security, in general, I think has never been more important. I think the software supply chain is just one aspect of that.
Thomas Betts: I think it's only related by two words, supply chain, but it's 2021, and supply chain to non-software developers means something completely different. So the supply chain being disrupted around the globe as we're trying to move materials. I know I'm in the US. We keep hearing about it, and the UK's got their own issues. And I just wonder if, with the move of everyone away from offices, coming back to our first topic, everyone's working remote, and we're getting more and more to we're just moving around electrons and not molecules.
And it's not just software that's the supply chain. It's the product that we're delivering is software. And do we have to worry about how does that change and how much more important does it get? It gets to those issues of security. Do people start just getting into just having more software around? I know we thought about talking about NFTs and the metaverse. And if it's just this virtual world we're living in, do we have to worry about that getting disrupted someday? And how do we think about that before it's too late and before it's happened?
Wes Reisz: There was the segue into crypto, into blockchain.
Wes, any thoughts about NFTs and blockchain? [47:04]
Daniel Bryant: Wes, any thoughts about NFTs and blockchain?
Wes Reisz: I do. Obviously, I have a ton of them. Back to ethics. Back to green. That ties this all together, doesn't it? I'm looking forward to seeing some really viable and powerful use cases of blockchain come out in 2022. So for example, talking about non-fungible tokens, I read something about the gaming industry using NFTs to be able to create truly unique digital assets. So you talked about metaverse just a second ago. Well, metaverse being able to buy something that literally there is only one of or a limited number of, and you're able to purchase that.
I know it's gaming, and it's maybe not as exciting as decomposing the monolith or anything like that. But I think there's something very interesting about being able to create, in a software sense, a verifiably unique piece of software that can travel with you across different games. So I think there's some interesting things.
Ethical situations definitely have to be addressed. 100% agree. But I think that blockchain has some potentially interesting things. I personally would like to see some really strong use cases, maybe around privacy, a private healthcare record using blockchain. Hey, who wouldn't sign up for that? There's some interesting use cases (I think) out there.
Thomas Betts: Is blockchain possibly a solution to the software supply chain issues? Because I pull in how many NPM packages and nougat packages in my code. I don't know what all that code is. No one that I work with has read through every line of code that is deployed on all of our software. You mentioned Docker Hub. You don't know what you're running, and you work at higher levels of abstraction. You cannot possibly know, and yet you're still responsible for that. So is there some way to certify, this is actually what I ... Well, it's open source, they didn't pay for it, but this is what I paid for. This is actually what they said it is.
Daniel Bryant: So it is worth mentioning. Companies like Docker are running programs now to verify certain assets and certain containers. You can actually sign up and get Docker-approved containers. And then basically say to your enterprise only containers that have been signed, tested, a certain thing can be brought into your supply chain. So I think companies like Docker are recognizing it, Amazon, a bunch of other folks are, and maybe it's coming back to what Charles, I think, said earlier on. Is it on the bigger vendors like your Dockers, your Amazons, your Azures to help with this?
Wes Reisz: Actually, again, VMware, so I have to throw it out there, but one of the products that we have is Tanzu Application Catalog, which does exactly that. It takes Bitnami and verifies things and allows you to be able to know what that software supply chain is and be able to give that kind of information. There are definitely products that enterprises are bringing forward to be able to address this kind of need.
Thomas Betts: Yeah. And I know GitHub's been doing some stuff to do verification, vulnerability scans of code that's checked in, watching the pipeline, so they say what's happening.
Wes Reisz: Yeah. Most of the registries will plug directly in, so you can scan a variety of tools. Yeah.
What is everyone most looking forward to seeing in the new year? [49:46]
Daniel Bryant: So as we are wrapping up the end of the year, looking forward to 2022, I'd like to get a few moments of everyone's time as to what they're most looking forward to seeing in the new year. Srini, let's get your thoughts first.
Srini Penchikala: Yeah. Thanks, Daniel. It's been great to chat with you all and discuss all the emerging trends in different areas. I think one key takeaway for me from this discussion is how all of these trends and technologies and practices are connected with each other. They're all different dimensions to the same thing. I'm looking forward to definitely the data engineering and the AI and ML solutions being, like we said, more ethical, more fair.
Srini Penchikala: If there is one area that needs the ethical aspect, it would be mission learning, because these are programs that are almost as smart as humans. Like we talked about, they aren't going to replace us, but they're going to make our jobs better only if we take time to make sure that they are ethical and they are fair. So I almost feel like we need a center of excellence or specialization to standardize the way of validating the ethical nature of these solutions.
Srini Penchikala: It may not start as a JUnit Test, but we need some kind of a testing approach, some consistent validation. For me, something may be fair, but for another person, it may not be fair. So how can we bring this definition of fairness to a common level so that way it is equally fair to all the affected parties. So that's my main area for interest next year, but I think everything else is going to accelerate as it's been doing for the last few years. The infrastructure will get better. There'll be new GPT models available out there, and maybe new Copilot programs we talked about will take us to the next level.
Srini Penchikala: And I just want to use a quick analogy before I wrap up is, we talked about programs replacing humans. It is almost like humans thinking that they can replace God. As scientists, we have been trying to understand the universe. Every day we understand a little bit more, but I don't think we can ever understand it fully what the creator has in mind and what's the university about. So we can get a little bit closer every day.
I think the same thing with the programs and the machine learning algorithms. They can get better every day. They can help us more and more, but I don't think they're going to replace humans. So they can only solve the problems right. I don't think they can solve the right problems. We still need humans to solve the right problems. Thank you.
Daniel Bryant: It's good to hear, Srini. It's good to hear. Yeah. Excellent. Excellent. Charles, what about yourself? What are you looking forward to next year?
Charles Humble: So there is something that I've just started picking up on that I think is really interesting. And actually, Thomas very briefly mentioned it in his last answer, which is that reading code as a way of understanding systems is a terrible way of understanding systems. And it's interesting because in the whole time I've worked in this industry, which is 30 years nearly now, all of the work that we have done has been focused on making the business of writing code easier.
So starting with things like better ideas with IntelliSense, all of those things, it's all about making the business of typing easier. But if you think about what you actually do as a programmer, you probably spend 50, 60, 70% of your time reading code, either code that you wrote or worse code that other people wrote, and trying to understand what it does. And I think we're just starting to see that problem being looked at.
I've spent quite a lot of time looking at the Ballerina language, which has come out in WSO2, and I think it's interesting, and that has built-in sequence diagrams to represent the concurrency model. And most sequence diagrams are literally a representation of the Ballerina syntax tree. So you can change the sequence diagram, and it will change the code. And it's just a really interesting way of understanding how the concurrency model works.
There is the glamorous toolkit stuff that Tudor has been working on. We had a talk on that at QCon Plus, which made my head explode. Because again, it's a way of building visual representations of programs as a way of exploring them, as a way of understanding what they do. I don't think it's the final answer to this problem, but I just got really excited that people are even beginning to think about it, because again, I think it's super, super important.
And I think, as an industry, it's another of those areas where we haven't really started tackling it yet, but I hope that we'll see more progress in that area in the new year. And I will personally keep banging the drum about ethics and sustainability. Because as you probably gathered, that's something that I think we all do, but it's something that I feel very strongly about and will use whatever platforms I have to try and just push that up the agenda for our industry in whatever little way I can. Because I just think, again, it's just so, so important.
I hope we'll see more work in that space, understanding what our impact is and how we might be able to reduce it, make it better. I hope we'll see more progress there in the new year as well.
Daniel Bryant: Perfect, Charles. Thank you much. Shane, over to you.
Shane Hastie: More humanistic workplaces that treat people well is what I'm looking for and I'm seeing. I wish it was purely because organizations just cared about people, but the cynic in me says they've got to do it because they're losing good people. And if you want to attract good people, you need to give them a great environment to work in. And going with that, a more ethical industry. I certainly see us moving towards that slowly.
Daniel Bryant: Wes, over to you.
Wes Reisz: I think, like Srini, what I got out of this discussion has been really working at higher and higher levels of abstraction. Everything we've talked a bit about is working at higher and higher levels of abstraction, giving us more reach, giving us more ability. And I think all that needs to be in the context of ethics and sustainability as Charles mentioned.
So what I'd like to see in 2022, I'd love to see more attention paid to sustainability. I'd love more discussion on ethics. I'd love all of that to be in the context of everything else we've talked about, but really sustainability and ethics, I think for me, is what I'd like to see in 2022.
Daniel Bryant: Very nice. Thomas, over to you.
Thomas Betts: I will agree with everything everyone said, so I don't have to repeat it. I already mentioned I think data mesh is the one little thing I'm waiting to see. Show me someone doing it as a good example, as opposed to just the high-level architecture designs. I think we're going to see something really interesting come about and people saying, this is the way to do this and here's how it works and why.
I'm surprised that no one's yet mentioned in-person conferences. I would love to have one that's not virtual. And QCon Plus is fantastic. Very well done. It's not the same as going and meeting people. So I'd love to see all of you and everybody else in a place that's not a super spreader event.
And finally, I want to see, maybe we can prove out my theory, the COVID corollary to Conway's law. Do hybrid and remote-first companies start writing distributed software better? And time will tell.
Daniel Bryant: Perfect. I think for mine I'll plus one everything everyone said, as you said there, Thomas. I'm really keen to see security get a good focus next year because we're only starting to see the tip of the iceberg on some of the problems. And it really is a problem for all of us in terms of ethics, data sovereignty, what you can and cannot do with data, and just the great power that we have as engineers. So yeah, I really hope a lot of focus on security next year.
I'm really passionate about developer experience. I think these control planes on the multi-cloud world that we've touched on are super important as we bring in different services and different clouds. We as engineers need to understand things better. As you said, Charles, I think that's a really, really key thing. Something I struggle with as a distributed systems engineer these days is just understanding the system I'm working with.
Daniel Bryant: I'm excited. There's lots of innovation happening in this space. Lots of VC money sloshing around at the moment as well. Doesn't always correlate with success, but I do think where funding is going, we will see innovation happen. So super exciting times.
At that point, I'll say thank you so much, everyone, for joining us. Always a pleasure to hang out with you all and chat. Massive plus one, Thomas, to meeting in person. We have got QCon London and other things on the agenda. So we'll put links in for interested listeners to follow up. But any final words from folks?
Shane Hastie: Just been great to see you all virtually and looking forward to truly being in person one day.
Srini Penchikala: Yeah. I second that.
Thomas Betts: Yeah. Be safe.
Additional resources
- The Spectrum of Synchronousness
- Building the Enchanted Land
- Green Software
- Microsoft's Asim Hussain on Designing Software for Sustainability and the Green Software Foundation
- Open Policy Agent (OPA) with the Project’s Co-Creators
- Meenakshi Kaushik and Neelima Mukiri on Responsible AI and Machine Learning Algorithm Fairness
- Francesca Lazzeri on Machine Learning for Time Series Forecasting