We are excited to announce that we have just released BigFlow 1.0 as open source. It’s a Python framework for big data processing on the Google Cloud Platform.
Due to the high interest and controversy concerning this blog post, we believe that it is worth adding some context on how we work and make decisions at Allegro. Each of more than 50 development teams at Allegro has the freedom to choose technologies from those supported by our PaaS. We mainly code in Java, Kotlin, Python and Golang. The point of view presented in the article results from the author’s experience.
Some of our engineers run their own tech blogs. We encourage them to move here, but for various reasons, they prefer to publish on private blogs. We respect their decisions. What we can do is to gather all the blog posts published by allegro.tech engineers around the web in the one place.
High performance and availability are always hard to achieve, and microservice architecture is no exception. In the microservices world, every user request sent to a frontend application triggers a cascade of remote calls. The frontend application calls API facades, API facades ask backend services, backend services communicate with databases and even more backend services. Statistics work against you. Latencies add up but failure probabilities combine by multiplication. The more services are engaged in a flow, the more threats for performance and availability.
This article is a part of CQK Top 10 series.
Microservices are now the mainstream approach for scalable systems architecture. There is little controversy when we are talking about designing backend services. Well-behaved backend microservice should cover one BoundedContext and communicate over the REST API. Things get complicated when we need to use microservices as building blocks for a frontend solution. How to build a consistent website or a mobile app using tens or sometimes hundreds of microservices?
The story begins two years ago during an excellent TDD training given by Szczepan Faber and Tomek Kaczanowski for a bunch of Allegro developers. Surprisingly, it was a trigger to revolutionize our builds at Allegro.
There are two parts of this article. In first we define what is Capacity (maximum load) and Resilience (fault tolerance) of a typical e-commerce site.
JDD conference is behind us. We had a great time doing a github dev contest (Chief Troublemaker Officer) for conference attendees. Some guys complained that the contest was too hard, good to hear! It was out intention not to make it too trivial.
If you are going to be in Kraków for JDD conference, October, 13-14th, don’t miss a perfect opportunity to meet our Allegro engineers!
Software engineer with 15+ years of professional experience. He focuses on lightweight and modern technologies around JVM. At Allegro, he works as a development team leader. JaVers project lead. Spock advocate.
