The simplest possible strategy that can help with communication issues is retrying to execute the request again. Maybe it was just a network glitch and it will work just fine when you try to call it again. Introducing retries is a relatively simple step that can improve the stability of your service. But before adding retries check if you’ll not be waiting for 2 minutes for establishing the connection…
At work, we are splitting the monolithic application into smaller services. From time to time we have some challenges in doing it the right way. Lately, most of the splitting is focused on cutting out frontends to be outside of the monolith. It gives solid results as we are getting logic and business rules in one place. The downside is that most of the communication has to be synchronous which creates interesting problems to solve.
In this post, I’d like to show you how I’ve started with writing this blog. How the process evolved during 3 years of writing. How I’ve finally managed to set up everything in a way that works for me now. If you don’t blog yet this might help you out with technical details on how you can start easily. If you already have a blog maybe you’ll be able to pick up some ideas.
On almost every job interview there are questions about frameworks, programming principles, maybe some coding or whiteboard architecting. On the other side, there is the way you work. Tools and skills you use on a daily basis which define how you work. No one really asks about those things but I find them quite important.
At work, we are slowly breaking down the monolithic application into smaller manageable services. Some time ago we had a very interesting issue which proved that microservices are hard to implement. It’s especially true if you are not there yet but somewhere in the middle. When you need to introduce intermediate solutions which will enable you to work further on the migration to service oriented architecture.
I’m learning python for some time now. I’ve made myself familiar with the syntax and then started looking into other ways to increase my knowledge about language and learn its quirks. I’ve found a very nice site that allows me to practice basics and strengthen different kind of muscles that I’m using in my day job - adventofcode.
At work I’m are engaged in the maintenance and development of a pretty big legacy monolithic application. Some time ago team size basically doubled. To keep things simple and activate more people we decided that we need to split the huge team into smaller more focused parties. Here is how we are working on many features of the same code base in single monolith with multiple teams.
It all started on Friday, like many of the bad things that can happen in software ;) We’ve been working for some time and after being blocked with deployments for a long time (don’t ask, you don’t want to know ;)) we were finally able to deploy a new version. Our last release was about week ago. Do the deployment - seems like the easy thing to do. I’ve triggered deploy plan on Jenkins and it’s failed. Here is the story how I’ve fixed something that looked like hours of analysis in few minutes.
Recently while starting work on a project we’ve (team of two ;)) decided to try something new and use Kotlin. The project is far from ready and still under active development, but after writing some code in Kotlin I’ve got few observations I’d like to share.