In a previous post we saw an NGINX configuration to allow gRPC traffic mirroring. Is the same technique applicable on Kubernetes? Yes! Using the ingress-nginx ingress controller! Traffic mirroringUse the following configurations snippets in the ingress-nginx configMap and in the Ingress manifest to mirror all traffic to a separate gRPC server. ConfigMapReplace and with the original and mirror endpoint, respectively. 1 2 3 4 5 6 7 8 9 10 11 12 http-snippet:|server { listen 127.
Recently at work with the Optimyze team we faced the necessity of copying traffic from our current customer-facing environment to a new environment. We have assumptions and ideas about architectural changes that cannot be validated only with synthetic tests and require cloning traffic to a separate, internal testing environment. There is no better test than the one performed with real-world data: when you hear speaking about testing in production, a deployment of a new feature to “see what happens” is not what I have in mind.
I have been using micro-committing for some time now, during which I have adapted the usage of this technique to my needs, bringing it to a level that makes me more productive than ever in software development. Combining micro-committing with Git, while doing TDD is now my favorite development experience: I like how this workflow helps to deliver changes with speed and confidence. This is not a one-size-fits-all approach, I’m sharing what works great for me; I hope some parts of what follows will help you and your team as well.
Yes! Yesterday I received an awesome email stating that I cleared the Certified Kubernetes Administrator exam! 😎 Here I want to report my experience in preparing and taking the exam, hopefully this info can help others Kubernetes practitioners get the certification too. PreparationI consider myself lucky because for the past two years I had the chance to use Kubernetes working at; on top this on-the-job training I went through a lot of studying and practicing because the exam itself has a lot of content.
I’m more and more fond of finding the perfect solution to manage application delivery: dev teams want to be fast but their ops counterpart is not happy to loose control over the growing number of deployments that could cause an outage. We as an industry need to find the right balance to have features delivered in time and keep the service up and running for our users! And that’s where progressive delivery can help!
I’m in the train back from GoLab 2018 and I am so happy that I attended this conference! It’s been definitely one of most beautiful con I have attended in Italy, with tremendous speakers from all over the globe like Filippo Valsorda, Eleanor McHugh, Ron Evans and Bill Kennedy among many others; I have to say the organizers were just perfect in everything from the venue setup to the workshop organization, as if the quality of the talks ware not enough.
Cloud-native: sounds attractive right? What does it even mean? Wikipedia has no page on it already so anyone can give its own definition… Here’s mine: A Cloud-native application has only concern on the functionalities that it has to deliver as it is completely decoupled from the infrastructure it runs on So how can software delivery be cloud-native? Isn’t software delivery supposed to “install” software onto some infrastructure? Well if your infrastructure provider is cloud-native, you can transitively deliver software on it in a cloud-native way (counts of cloud-native is over 9000, so stopping here)!
Continuous Delivery should be a solved issue: the practice is well-defined and there is a plethora of tools implementing it with more or less peculiarities, but still many struggle implementing it. The dream of a perfect continuous deployment flow from the developer to the production environment with software quality gates based on automated tests is still alive in me, I tried and tried several times with multiple implementations on multiple platforms and never got to the point where I could say: “I’m done, this works exactly as I wanted”.
Kubernetes is the de facto platform for running modern applications: its broad adoption in 2017 and the velocity of the project made it so and it’s been accepted as the standard for many companies, from small to planet scale. It was impossible that such an extensible platform would be left out the serverless party, so here are the 4 main players offering FaaS to be run via k8s. A premiseIf you’re new to serverless and FaaS and all the previous buzzwords sound like cacophony to your ears, I really recommend reading this post and watching this talk.
In the early days of Go the language was often tailored towards “system programming” due to its C-stlye syntax and ability to write high-performance applications. Few time after, Go adoption was starting to gain traction for distributed systems development and projects like etcd, docker and kubernetes revealed the power of the networking capabilities offered by the internals in the language. Along the way a lot of libraries have been built around the powerful primitives offered by Go but in my opinion there is not enough use literature around the Communicating Sequential Processes implementation available through channels and goroutines, they are not even widely used in the standard library.
One of the advantages of containerized applications is the standardization, some would say “write it once, runs everywhere” but that’s another motto for another product. Anyway with a new packaging technology the same problems are faced: build reproducibility, or the necessity for people doing Ops to know they are going to deploy the same exact piece of code the Dev team used in their tests. So to address this issue the container image needs to be immutable: once it’s built, it’s not going to be changed, ever.
Recently I received a mail pointing me to a post about DevOps culture and some anti-patterns and misconception on how to build and grow a DevOps culture in a company. Whoever like me works in the Enterprise (“the one with the big E” - Kelsey Hightower) knows that applying DevOps practices often is limited to the adoption of some tools or the creation of a “DevOps team” responsible of managing some continuous delivery pipeline.
Letsencrypt is cool: automated, free TLS certificates for everybody! They are sponsored mainly by internet corps and they started a crowd-funding campaign to avoid the influence of this corps in the future of the project. I recently moved the blog to hugo on AWS and I’m now porting the TLS management scripts I wrote a while ago on AWS: this is a nice exercise to give a proper TLS automation valid for everyone on AWS.
Last month I felt I was a little late for the #serverless party going on all over the internet and I started taking a look at what the pros and cons would be to actually not manage any server myself. Shutting down my VPS hosting my apps I will lose my mail server, my MySQL instances and my Docker registry but: who cares? There are cloud services I can use with hundreds of times more availability and for a fraction of the cost.
In times of experimenting, I am now having a lot of fun with docker, rkt, kubernetes and containers ecosystem in general. But one thing I never forget to play with is content editing and publishing! So here I am, trying to migrate all my blog and website to Hugo :) So instead of a bare VPS I am moving my blog to AWS S3 + Cloudfront CDN. This will be more scalable and far less expensive.
Amazon Web Services Elastic File System has been to my knowledge the service to have the longest beta testing period: reason for this may be that not as many client as expected tested it and AWS received too few feedback on it or that there were issues not to release GA. I don’t want to speculate on which one is correct but now that it has been officially released I decided to give it a try and of course compare it to a self-managed solution on the same platform.