One way to reason about distributed systems are that it’s capabilities reside in distinct systems.
There are plenty of articles online discussing “monolith vs microservices”. However the reality is that a monolith or a microservice is just one part of a set of disparate systems which together make your business application(s) capable. In short it’s already a distributed system.
Lets make this more concrete with an example.
We have built a cool product as a monolith, but that’s just the application that contains the the business logic.
We also have:
Software systems can be created in many ways and micro services are certainly a valid choice, but its name makes it too inviting and simplistic.
An English definition for the word micro is “extremely small”.
An English definition (among others) for the word monolith is “a massive structure”.
Who doesn’t want to build extremely small systems as opposed to a massive structure. Naturally micro services should be the way forward.
Although I doubt that the micro services being built are in fact extremely small, rather what’s probably being built are services which are smaller than what was there before.
An bone of contention among developers is whether one can become a good developer by just doing your regular nine to five working hours, or if extra effort out of hours is needed.
To be able to address this, one first needs to answer “What is a good software developer?”.
My definition is simple: Someone that you can rely on.
Given the above, my personal experience is that (in general) it takes more than the regular nine to five working hours to be a good software developer.
It should be noted that I do not advocate hard and fast rules…
If I could go back to the time when I was starting out as a developer and ask my current self “What should I do to become as good a developer as I can be?”, then my answer would be “it depends”.
Only joking, but seriously the more you learn, the more you realize how little you actually know and so naturally it depends.
But to the hopeful, energetic young person I once was, I’ll give some advice. Keep learning and keep practicing.
Okay, something more concrete then. Here is what you should learn and practice.
The introduction in this…
In this article I’m going to be using Spring to demonstrate the various gotchas.
The intention of the project is to get data about when cars were sold, and be able to aggregate the data based on year and make.
By using the Spring and Kafka documentation one can create a kafka streams application to do this quite quickly.
However some of the things that go on behind the scenes may catch you out and I’ll be focusing on some of those.
Let’s begin with an analogy.
Given there are four seasons in a year, would you wear the same clothes each season? You could, but it wouldn’t seem the wisest decision. Adapting to one’s surroundings by applying the necessary adjustments would result in more proportionate attire.
Adapting can certainly occur via trial and error, but greater success can be had by applying curated knowledge.
The same applies to software development, where building, maintaining and improving software systems requires us to continually improve by tapping into that knowledge.
I’ll digress a bit to take a general and simple perspective of the impact…
It’s apparently a developer’s market, with more demand than supply.
So, given the plethora of opportunities, you’d want to put your: “Do you have any questions for us?” to good use and create a profile of your next potential employer, so that you can make the most informed choice before you decide to stay or leave.
Effectively, as the title states, the idea here is to interview your interviewer.
Here are some questions that can help you build that profile (if time allows).
Do their expectations of me at least match my own expectations?
When absolutely sure or in doubt always answer with “it depends”.