Lukasz is the Principal SA Team Lead at AWS. You can read about him on his LinkedIn but this peer talk was not a discussion on anything related to solution architecture, it was more about how a leader thinks and how his experience and vision can help to in a certain way which helps to maximise your output for the customers, meeting him in person made a huge difference to me in so many ways !!!
Lukasz shares his experience in such a way that you always learn something from that, and the way he listens to little details and constructively corrects them in the most informative manner taught me one of the most important skills of handling a conversation. If you ever have a chance to attend re:Invent and you have a chance to book a peer talk with Lukasz, please do so; it will be a complete game changer to your status quo understanding of things and how the in the real world customer expects your output as an engineer.
In this peer talk at re:Invent 2023 we discussed many things like which is this new buzz around "Platform Engineering", to what extent we can integrate AI with the DevOps process, and limitations to operations of taking a left shift security approach.
Note: This blog will be in QnA form, the views and opinion of the peer talk expert and author are their personal views and not associated with or endorsed by their organisation.
Q: How do you feel about the latest shift of DevOps from platform engineering?
- Lukasz: Right from the inception I have always thought of DevOps as a culture where organisations needed that mindset and strategies to bring agility and achieve the agile delivery for software. Platform engineering is another cycle in terms of mindset and approach, strategies to help tenants(customers/developers) to perform seamless provisioning of infrastructure without actually worrying about how is it being performed leading to shorter development cycles.
-
Jatin: I somewhat agree here but why I don't have a complete agreement? DevOps has such a vast scope of operations involved (Infrastructure(IaC), pipelines, observability, monitoring and alerting ) that I think it is natural to see it as skills which are separate from developers and therefore it turned out to be a role now.
However, with platform engineering, I think it is a mindset and strategies at this time for DevOps engineers to make because there will never be one successful strategy for a platform because each platform will cater to different customers and requirements. It's still soon to say but once Platform Engineering has some sort of standardisation and patterns I think this will also turn into skills and roles.
Q: What are the guiding principles of Platform Engineering?
- Lukasz: The concept of platform engineering has existed from even old days; connected with the heaviness and complexity of tech we were dealing with, when these systems were monolithic and not distributed. The modern approach will be how to approach monolithic services and distributed architecture.
-
Jatin: There are 2 patterns or principles so far related to platform engineering I have seen:
- 1: Where there is a single product and tenants(application team) have to provision resources using the platform (simple and easy)
- 2: Where there are multiple products(customers) and tenants(application team) have to provision resources using the platform. This is a complex scenario because now we may need to establish multiple platforms after finding some common base operations.
- Lukasz: No matter how much we think about guiding principles, the way I have seen so far with customers is that they will always take the practical approach. They will prefer things which suit their business and organisation, how it will help them achieve scalability and that edge in the market, such sort of practical approach is taken by the companies. For now, when it comes to platform engineering as this concept is still in its infancy stage this will be a difficult discussion because we still don't know what will be more accurate the practical approach of customers or some standard principles of platform engineering.
-
Jatin: Never thought from this perspective that this is always the practical approach that customers prefer to take. And yes the more I think about the relationship platform engineering principles and practical approach i get more clueless for now :)
Q: How to integrate AI into the DevOps process? Do you suggest to the customer to include AI tools?
- Lukasz: It depends on to what extent you can integrate. As developer, they want to use AI in the sense that do this for me and don't tell me how you do it, just do it. I had a customer who had a sound tech team but they were still struggling with certain things after introducing them to code whisperer they were super happy with how it improved their productivity and solved their problem
-
Jatin: Since you mentioned Gen-AI, I want to mention about Amazon Q (the latest release). Since the AWS ecosystem is so wide and deep a gen-AI which is integrated with an AWS account is the need of the hour, so far all good but I am still not happy with the use case I am looking for, for example, I want Amazon Q to be integrated with EKS, and whenever my cluster has a problem, I want Amazon Q to tell me the cause and potential fix to it.
-
Lukasz: Yes, we still don't have that sophistication of integration with AWS services when it comes to AI tools but I think Amazon Q has laid the foundation for it, let's hope for it.
Q: What do you think about the left-shift approach when it comes to infrastructure and DevOps processes?
- Lukasz: DevSecOps has been here for a long time dealing with adjusting security. With the emerging trend of zero trust, there are 2 reactions which I see to be very common: there is a huge interest in having security right from the start now whether it's the development cycle or infrastructure, another reaction would be that security can slow observability.
-
Jatin: I do agree that security not only slows the observability but it also slows down the operations. For example, I wanted to introduce an AI-based tool to the EKS cluster to my customer but I couldn't because I was worried about the data that the tool would read what amount of information would be shared and so on. It's a must and very important thing to take a security-first approach but finding a a balance is always tough.
I had a great time discussing about topics i was curious which was also my purpose for this re:Invent, If you have any questions related to this peer talk or any other opinions about things I have discussed feel free to ping me on LinkedIn
2
