Posts

Showing posts with the label chaos

Chaos Engineering with ToxiProxy

Image
Chaos Engineering is an important discipline of modern cloud-based services. Failure will happen no matter what and it's improved to prove your infrastructure, code, and configurations are reliable and can resist failure and proper recovery. The only way to know is to either by the worst way possible i.e error 3AM on Sunday night or you can test it and sleep better at night :-).  ToxiProxy from Shopify is a pretty useful and interesting solution. It's a proxy that allows us to introduce all sorts of network chaos in our applications such as latency, hang, timeout, and much more. ToxiProxy is written in Go and you can run the server in a self-contained executable like all Go good stuff. ToxiProxy has multiple clients in multiple languages. I will demonstrate some chaos with Redis using the Lettuce driver in Java and ToxiProxy java client library.

My 2 Cents on "On the Diverse And Fantastical Shapes of Testing"

Image
I want to share my cents about the post: " On the Diverse And Fantastical Shapes of Testing ". First of all, I believe this is a very interesting subject and yet still see very few engineers talking about it. People mostly take tests for granted. Secondly, I would like to acknowledge the parts I agree with on this post mainly around the concept of Sociable and Solitary Unit Tests are quite useful and show be widespread. Also with the need for teams to have reliable, fast, Bounded(Isolated) and not Flacky on Justin tweet . Now that I acknowledge that, let me elaborate on what I think we are missing and why IMHO the pyramid is dated and we need a mentality shift. I have 4 points I want to elaborate on and give more context.

Chaos is the New Normal

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

Anti-Fragility Requires Chaos Engineering

Image
There are lots of buzz around microservices and everybody want do it right now. The main problem is people are not providing the right level of isolation in sense of operation system or containers, database and interface without that microservices are just webservices with REST. When you go from 10 services to 100 you create more distribution, more distribution is more failure, for sure the network is not reliable even with a cloud provider like amazon web services. You need anti-fragility on the DevOps Era we live, why? because otherwise we just changing the names but doing the same mistakes as before. You will built and operate software automated, not only your deploy pipeline, but them that's enough? No is not at all, why not? Because your software and your infrastructure will fail, and as Vogels from AWS said, all the things fail all the time, you need be able to quickly recover, if you need that, them we need 3 basic things. 1. We need Design For failure You cant do it late...