Diego Pacheco Tech blog

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...

Dynomite it's a great solution for clustering with NoSQL Databases like Redis . Eureka is a nice Registry & Discoverability Solution. We can get best of both worlds using Prana . Prana is a sidecar that enables non-JVM applications to register in Eureka. Sometimes we could easily use multiple discoverability solutions like DNS, ETCD, Eureka etc... However not all discoverability provide the same benefits some tools are better suited for some jobs them other. I like ETCD and make sense onKubernetes world but if you are doing Java Microservices eureka makes more sense. The triad(Eureka, Prana, Dynomite) is great, This is great because then you can do discoverability on your database nodes, this is not great for several reasons like: Use the same tool for Registry / Discoverability Enable all sorts of dynamic programming which is great for DevOps Engineering Avoid AWS Throttling issues Make dyno clients more dynamic and this is a better solution them DNS like route5...

The Stability Mindset I have background on software development. Currently, I'm leading a team of highly effective engineering's where we are responsible of some of the components we delivery in production and I need to say that is not the standard reality on it market. Development is used to break things and move faster, however, lots of developers never cared about production or about “polishing” they systems. This effect happens some several reasons like: Having different people to develop and operate software Having different departments for development and Operations Having development teams focus too much in new features rather than real UX So there is this culture clash when we have developers doing DevOps Engineering(I say that for my own experience). We developers are not used to keep something running no matter what. To be always available and reliable. It takes some time to get this “Stability Mindset” but once you get it is hard to get out of you...

Tests are at same time a simple and a complex subject. Testing is something basic. Are you don't do testing how do you know it works? How do you know your software won't stop working after some refactorings?. Unit Tests are the basic level of testing you could do.  In the past unit test was normal. When we deliver software we need to deliver unit tests whiten so level of coverage. When we talk about coverage things can get tricky since you might end up coding tests for parts of your application where it is little or no value what so ever. Coverage can be something questionable as you language might force you to do less or more tests. For instance is you have a strongly typed language where you enforce as much thing as you can via compiler you might need to do less testing since the compiler works in your favor.  As you work with more dynamic and weak-typed languages you might need to do more tests since the compiler might catch fewer things. As much the language e...