October 16, 2024

DevOps and Plaform engineers differences, is DevOps death?

From my perspective DevOps is about combining development and operations into one coherent group or team capable of delivering applications from the initial concept all the way until production, and then, also making sure that it continues running in production right. I think it’s about creating those self-sufficient teams.

Platform engineering is about creating internal tooling, an internal platform that is tailor-made for the needs of a company that combines all the tools the company uses, and creates that abstraction layer on top that simplifies usage for everybody else.
A person might have seven years of experience in Terraform but it’s unrealistic to expect that everybody will know everything about it, and even more unrealistic that everybody will know everything about AWS, Azure, and so on, so Platform engineers are in charge of developing such internal tooling that simplifies specific processes in a company, and enables everybody else to do things instead of opening Jira tickets.

The question that keeps coming up is if DevOps is a sustainable career or if is DevOps dead?.
From my perspective, in the last 20 years, I’ve been a Computer Technician, Java developer, Java Senior developer, Network Administrator, Sysadmin, Software engineer, DevOps engineer, SRE, and probably some other things. But in all of those, I’ve done the same thing, I’ve implemented things to help businesses to be more profitable and to grow.
So the title really doesn’t matter, as long as you focus on adding value, you’re always going to have a job. So is DevOps dead? I don’t know. And I don’t really care. And sincerely, I don’t think you should either.

September 3, 2023 by Fernando SRE DevOps stuff 0

Getting into DevOps and its future, personal opinion.

DevOps is basically making the work of developers and operations automated more efficient and seamless, right? And since we have like a separate role as a DevOps engineer, basically what you do, the main responsibility is to take what developers have created and seamlessly in the most automated efficient, fast, secure, whatever way basically release it to the end users, right? So the whole process of taking that coded application, putting it on the end environment, and making it accessible to the end users in a secure way, in a highly performant available way, that’s the main responsibility of DevOps.

If you want to get into DevOps, you can use the software development entry as a first point, and then, even as a junior software developer, you can start transitioning into DevOps, because you would have enough foundational knowledge as a “prerequisite” to start learning the things that you need in DevOps.

DevOps is still relatively like, compared to other IT fields I would say relatively young, and there are a lot of things going on, there like a lot of dynamics, and you could see like a lot of different technologies that are being developed and invented for different use cases, or like problems that you have in the DevOps projects. And you also have like a lot of similar technologies developed in the same area, which is actually a sign of the fact that there is no one standardized solution for that. So I believe that the market trend, and the way that in the direction where DevOps is going to be developing, will be to standardize the processes more. To have like a few sets of tools that most of the projects, like 90% or maybe even more projects, will use. And all the rest of the technologies will just disappear because there has to be one winner in each category, so I think that’s going to be the trend versus now, where you have like ten or more different tools to choose from which are super similar for the same task, and then you have this thing, because none of them is super standardized, and the one that is mostly used, so you have to choose between them and evaluate them all the time.

But I think it’s going to standardize a lot more, and generally DevOps, because it’s becoming mainstream already, and we see that, that DevOps itself is going to become more clearly defined, and there will be like more clarity from the companies, what they expect from a DevOps engineer, where is the line between developer and DevOps engineer, where is the line between operations and DevOps.

I think that’s going to be in like, maybe four or five years, we’ll see that kind of standardization.

August 28, 2023 by Fernando SRE DevOps stuff 0

AWS IDP Short reference Architecture

Organizations must be agile and innovative to stay competitive in today’s software development era, which has led to changes in how applications are built, deployed, and managed.

This necessitates the transformation of static CI/CD setups into modern Internal Developer Platforms (IDPs) that provide developers with the tools needed to innovate and move quickly.

While every platform looks different, specific common patterns emerge. To help simplify things, I’ve consolidated the platform designs of dozens of setups into standard patterns based on real-world experiences, which have been proven to work effectively. By adopting these patterns, organizations can create IDPs that keep them ahead of the competition and deliver innovative applications faster.

This diagram provides an overview of one reference architecture for a dynamic IDP using AWS EKS, RDS, Backstage, Humanitec, GitHub Actions, Terraform, and several other technologies.

Design principles.

01 Focus on the user. The most important customers of a developer platform
are developers. Developers need to be heavily involved in the design,
prioritization of features, and testing to ensure the platform is fit for purpose
and fully self-service.

02 Run your platform team like a start-up. Establish a small central team that
owns the platform and is responsible for marketing it, ensuring it is easily consumable and fulfills developers’ needs.

03 Build golden paths vs cages. Developers should be free to choose their
abstraction level. While your IDP should provide a set of golden paths for developers to follow, it should never force their use.

04 Drive standardization by design. Enabling self-service means platform
engineers must define how to vend resources and configuration. This ensures
every resource is built securely, compliant, and well-architected.

05 Implement Dynamic Configuration Management. Dynamic Configuration Management significantly reduces config complexity and enforces standardization by continuously generating app and infrastructure configs with every single deployment. This allows you to enforce policies and standards with every git-push.

06 Let developers decide on their platform interface. The developer
platform should never break your developer’s workflow or force them to use a
specific interface. To support this, a code-based workflow by default works
best, with the option to use a UI, CLI, or API.

07 Keep code as the single source of truth. This ensures everyone is working
from the same version, reducing the risk of errors.

08 Assume a brownfield scenario. Use tools that have already been
productized and adopted by the organization (such as backlog management,
CI/CD toolchain, and container platform) and let the existing teams pursue
integration through plug-ins into the platform. Where applicable, organizations
should use open-source tooling and a cloud-native approach.

August 27, 2023 by Fernando SRE Cloud stuff 0

Blog NivelEpsilon