Diego Pacheco Tech blog

The IT-industry always got 1 thing of of 10 and just because they have 1 thing they think they got the point. I saw this with SOA, REST, Agile and now DevOps is happening too. Yes i will say one more time that the DevOps team is wrong. Is so wrong, is not just a name and is not just a matter of practices. More and more a see what the it industry got from DevOps is CLOUD and Automation - witch is great because this a very important aspects of devops but however devops is way more than that. The confusion a SEE is calling OPS -> DevOps, OPS is OPS, OPS is not DevOps. You have Dev in your company a most likely have a ITIL shared OPS in your company so lets say you have 100 developers mostly you have 20 DBAs.

DevOps is everywhere, its everybody talking about and like any hype has lots of people getting it so wrong. So DevOps is not a process, its not a tool its not a department is not a tool is not a specific technology. DevOps is about culture - how to you build and operate high scalable systems.  DevOps for me IMHO is a LEAN manifestation so its really needs be based on LEAN thinking and principles - At least i see this pattern a lot, lots of company that gets devops right are doing LEAN i dont think is a coincidence.  Unfortunately more and more companies are trying to make devops simple, easy, predictable and so scheduled, like in how many months and i be devops? 2 months? The DevOps Team  That`s the first and one of the most errors i see everywhere. You dont fix silos issues creating more silos - not at all. So before people might blame dev or might blame ops - but now people will blame the devops team so this is really just moving the problem to another place. Comp...

DevOps, as movement and set of principles, did a great job making Operations and development the same integrated thing pretty much. However, industry-wide implementations are not quite there. There is an overlap with SRE(Site Reliability Engineering), and quickly you find DevOps Engineerings, DevOps Architects, DevOps Directors, DevOps Managers. There are plenty of DevOps departments out there. The same noise happened with Agile, where the company structures do not change, and silos still exist. Now we are about to extend the reach of DevOps to Security. Belive me of not the naming does not bother me much. There is a DevSecOps manifesto.

I saw this happening with other movements before, sooner or later I knew it would happen to DevOps. Culture is so fragile. Culture is fragile because it rely on people vision. It's so easy to understand something wrong or just deliberately misappropriate from something in the wrong way.  DevOps is something hot today and more and more companies what be part of the party.  If you are familiar with the Agile movement, something it happened with it before. There is no what or ever written on STONE DevOps Definition however for me it's 100% clear what DevOps is NOT:   - It's not a Tool   - It's not a Service   - It's not a Team   - It's not a Department   - It's not a Certification   - It's not a Role

Everybody is talking about DevOps now, which is good, but honestly DevOps is way bigger than what people are talking about. One of the CORE roots of devops is AUTOMATION of infrastructure - automate everything, that's true and that is so important, but that is not the only thing. DevOps is not a framework, is not a model, is not a process - DevOps are some experiences from folks around the globe who have had success in extending agile to new frontiers like operations - some people started a movement called Agile Operations which I think is great. DevOps is in some sense the evolution of the cultural change that agile and Lean promoted in development from the early 2000s. Now is the time to break more silos and continue to improve things. It's not easy, changing culture, but it is a necessary step for the evolution of software development.

Lessons Learned with DevOps Engineering Experiences Almost 20 years ago an Agile movement was born. After 20 years there are still lots of confusion and misunderstanding on principles, practices, and mindsets. DevOps barely have 10 years but does not have a method like a scrum, Kanban or XP. However, DevOps rely on Lean / Agile there is no strict definition, method or formal guidance how to do proper DevOps.   Like everything in life, this is good and bad at same time. DevOps is a movement about experiences that made some for some companies and people in order to have or practice better ways to develop and operate the software. Currently, DevOps is a mess. DevOps is a mess is Brazil but is also a Mess in the USA. For lots of people, DevOps means Ops doing code. For other companies DevOps means Cloud Ops Team doing ops. There are DevOps folks from Development background like me and there are much more. There is so much confusion on the market that you really need...

DevOps is hot. We know that because a DevOps certification just popup on the pas weeks. Claimed by the DevOps Institute( http://devopsinstitute.com/ ).  If you pay attention is very similar to the scrum certification and the devops community already start to wondering if this would be really possible to certify someone of doing "DevOps".  You can take your own conslusions checking out this link here =>  http://devopsinstitute.com/courses/ . You can read Sam Newman blog post here . So this raises all kinds of questions like what you think is DevOps or how easy is to make sure people are doing it right or worng and what would be the assessment criteria for the cert?

DevOps Monolith The term Monolith it's often used in legacy systems or system poorly designed and poorly architected.  Microservices are the facto stand architecture when we talk about software. There are lots of companies also doing DevOps Engineering and DevOps per se its related to microservices. Microservices required some infrastructure work like for instance: Provisioning : Install OS system packages, files, scripts. Telemetry : Dashboards and alerts for you microservice eco-system. Testing : Stress Testing, Chaos Testing, Load Testing, etc... Canary : Automated canary analysis, deploy, score, and rollback. Infrastructure work could be more or less depending on your level of abstractions for instance if you are working with bare metal or IaaS you will definitely have more things to get done. However, if you are doing cloud-native microservices using kubernetes or any FaaS stack you might have less work but always well have some infrastructure wor...

Some time ago I posted about some lessons learned by doing DevOps engineering and in the beginning of the year, I was posting some ideas and experiences(good and bad ones) around  Design and DevOps Engineering. I do lots of different things on my daily basis like Architecture, Software Engineering, DevOps Engineering, Chaos / Stress Testing, Reliability Engineering, Consultancy, Management / Coaching.  I'm lucky to run a team of great architects and also code every single day,. This provides me great insights since I'm executing things but also reviewing things other people do. There are lots of things I think every day but more and more I think about Design and DevOps Engineering. The right designs and how things get bad and complicated by the lack of good design. There are several elements of good design. I already cover some aspects in other posts and today I will cover other things like Assumptions, The Right Language for the job, Multi X Single language,...

DevOps it's a mindset, Skillset and it's not a Department. It's very common to see in the technology industry Centralized and Unique DevOps/Platform Teams. IMHO we are still not there. Most companies are still catching up on AWS and DevOps Engineering skills such as (Networking, Terraform, Observability, OS/Linux, etc...).  So DevOps centralized teams tend to be "Gate Keepers" for good practices and hygiene and several times cost zealots. That's is fine and has value, dont get me wrong. However several times unique and centrlized teams are just a pure form of a bottleneck. AWS has great infrastructure and tons of purpose-built services, I would argue most of the time you dont need to build anything in front of it. Using AWS directly could be coupling but as long as you use open APIs you should be fine. Several years ago I use to be bottered by coupling solution with ORACLE and with AWS the coupling is much bigger, not sure if any company would ever leave AWS, ...

DevOps Engineering is often "perceived" as a operations matter. In fact, it's true but is not 100% JUST ops. There are some blurred lines between engineering and operations. When we take a look at the DevOps ecosystem we can highlight some great tools like Ansible, Terraform, Jenkins, Packer and so many others. Provisioning, Release, Observability, and SRE are different aspects of a broader DevOps adoption. The higher benefit comes when we start applying more engineering to DevOps. It's very important to have good tooling around. When we think about tooling engineering makes a lot of sense, however, even outside of the tooling space there are areas where we definitely need an engineering injection like Cloud Production Operation Automation. Releasing is the easy part, things get complicated when you automate the operational aspects of your systems. It sounds so meta or Inception(If you watch the movie ) but Systems managing Systems looks the way to go for me. This ...

DevOps Engineering is about Workflow Currently, I work doing a bunch of different things(like most of Brazilians). I do Architecture, DevOps Engineering, Software Engineering, Agile Coaching and a bit of management. There different types of companies and cultures but basically or you are more specialized or more cross-functional I think in general Brazil is similar like Europe and more cross-functional and the US is more specialized but really depends on the company. I also run a small team doing: Dynomite / DM , Serverless Remediation, Stress Test and Chaos Platform and Telemetry / Observability. My teams need to provide solutions(engineering)but also Stability .

Today I want to share some experiences I had in the last 2 years with AWS Lambda as a Serverless solution for Microservices Remediation. This was not a single effort from me only but a team effort. The lessons learned I want to share with you today was not only in sense of Serverless but also in sense of DevOps Engineering. DevOps Engineering is the norm today. I really can't see a world without it. Code it is the lingua franca of everything around IT. Currently, there are more and more abstractions and solutions rising for DevOps Engineering, chances are we will need code fewer things as the time pass. However, as we push the boundaries of innovation we face new problems and new problems will always require better solutions. DevOps Engineering is great however it's not a FREE LUNCH at all, like microservices, which are great too, there are lots of COST that are introduced. There is a requirement do structure and lay down teams in a different way and also there is a need ...

DevOps it's about Design! As Steve Jobs once said: "Design is not how it looks but how it works". DevOps implies operation work through automation. People who do DevOps could come from 2 different kinds of backgrounds, you can come from Dev or from Ops. A good Developer cares about and really knows how to design applications. We do have several principles to design software. One of the basic and most important principles is Abstraction. Abstractions Abstraction means doing more with less and hiding complexity. It's easy to find automation solution with does not provide any abstraction at all. There is an easy way to get this smell which is the number of parameters you get from a Jenkins job for instance. More parameters means throwing complexity in your face it does not imply more flexibility. Having more options also can create more trouble for you because. Let's say you are using AWS and you receive the AMI_ID as parameter. Sounds like a g...

Eae galera blz? Sexta-feira passada rolou outra friday talk. Dessa vez falando de uma visão consolidada do movimento de DevOps e como ele pode agregar valor pro negocio. Além de novas técnologias e práticas para escrever e operar software. Nos estamos vivendo um momento de mudanças. Graças a DEUS o negocio já consegue perceber que se a TI não mudar não ser capaz de dar conta do recado. Muitos dizem que isso é besteira, mas a verdade é que nem todos querem mudar, nem todos querem sair da zona de conforto, isso tudo é OK por que a sobrevivência não é necessário é sempre OK piorar e ficar no mesmo lugar. Essa palestra sumariza uma serie de visões e experiencias sobre DevOps e experiencias de consultoria e delivery de TI dos últimos 5 anos. Espero que gostem. Confere ae, tem os videos e o slides :-)

Some time ago I was sharing my experiences with a Dynomite Remediation Process I wrote. Iḿ using remediation systems for a while and IMHO the add lots of value since they automate manual Cloud Operation work and save time for people. Currently, I refactored my Remediation code and now the same code can support Dynomite / Dynomite Manager but also Apache Cassandra. There are very similar concepts between Dynomite and Cassandra Remediation such as discovering AWS EC2 Ips to be remediated, AWs Resourcing(Creating SGs, Deleting LCs, Updating ASGs), Health checking(Is the node up and running? Could I remediate right now or you are in the middle of a backup or just booting up?). Once I identified that core concept I was able to create a high level and generic design for Cassandra and Dynomite. This is great for cases of Patch / Fix(apply a new AMI) or Scale Up(Increase the memory or CPU for instance). Although that the main use cases and most important ones there were some c...

Lean Thinking were and still is a big thing. The last Lean manifestation for me is on the DevOps Movement . That's the idea, unfortunately not every company is lean at all.   A Lean approach is everything. Some people may call it vision, which is the ability to think in a very specific way .  The reality is: It is broken and does not deliver what the business want. In order to archive high performance, you need more than just new techniques .  Think lean is not hard but it need to carefully put in practice every day.  It's very likely your company have a monolith application and you are trying to slice it and do DevOps like pretty much everybody else.

DevOps is not a tool, its not a service, its not a framework, its not a process, its not a role. DevOps is a state of mind and mindsets that your company wants get there to have better it performance.  This is hard and depends from culture and several aspects that are unique from company to company so there is no recipe for doing devops or right way.

AI might reshape how engineering works; there might be different workflows and different ways of shipping software. We have good and solid foundations in engineering, which are still relevant and can still guide us even in AI agentic times. If we go back more than 30-20 years, the traditional way of building software was highly influenced by RUP . From RUP come phases, roles, responsibilities, and structure. However, there was also waste, handoffs, a lack of focus on coding, and even a waterfall approach. After the agile movement, we learned that software could be built more effectively. Before we even start talking about AI and agents, we need to understand that companies have different levels of maturity and might not be all up to date with previous waves of innovation, such as Lean, Agile, DevOps, Lean Startup, and now AI Agentic Engineering. IF we look at the last almost 30 years of software engineering, we can notice a time called shift left. The idea is to pay more attention to q...

The world is changing. It's becoming more and more complicated. Systems are getting that as well, more and more real time, on-the-fly, available, concurrent, dynamic. If all that things are happening why we still suck when you talk about development and operations working together ? There is a old war between dev and ops, there're two worlds, two cultures, two totally different ways of thinking, concerns, there're 2 departments often with different managers, I don't talk about my company I talk about the majority of the world, there're this false dichotomy. Have you ever throw something over the dev or ops wall ? I did! It's amazing how still there're this wall and how dev and ops don't know how to work together effectively. Devs often think that the only that matter is teach ops how to restart the server and where put the God Damn EAR file. Ops often think there're is only life after QA. Both are totally wrong. If you have a stupid smal...