Hello again! Since our last post, our team has grown quite a bit — 30 percent! We’ve added some backend talent from Amazon and Cornerstone, and they’re already cranking out code.
We wanted to make this post about microservices and their pluses and minuses, but also didn’t want to reinvent the wheel by writing just-another-post-about-microservices. In our case, it really wasn’t an easy decision to determine that microservices were the way to go.
While there are blogs on blogs about microservices from a general perspective, there wasn’t a super convenient blog from an ag-tech company in our space letting us know their own experiences with microservices. Either way; we’re innovators, not followers, so we’re happy to trailblaze our way toward our own version.
A lot of the research when determining the viability of microservices has involved analyzing our current product with our current customers, identifying what will fit their needs in their current state, and then considering our future state and what will be required to support that vision. This is what has led us to settling on event-driven microservices for our approach.
We will tackle why event-driven is the particular approach we’ve chosen to go with in a later blog, but in this blog we want to talk just about microservices in general. Microservices actually complicate the system because we’re splitting everything into bite sized chunks, thus creating tons of bite sized chunks, but the benefits are worth it.
In particular, the main benefit of microservices is that it streamlines our development process, because we’re working with smaller pieces that are easier to split up. We can then quickly and simply distribute these pieces to different engineers, who can then work independently, in parallel, as fast as possible.
It only takes about two weeks of work to build one microservice; once it’s done, it’s done. This means that we can create fully functioning, standalone services without having to work as part of a team, without relying on others. We kind of envision it similar to a child eating food; if you just give a kid a huge chunk of food without cutting it up, it’s going to be very hard for them to get through it and process it.
This is the same for development, too. If the kid’s parents both spend time cutting that food into bite sized pieces that are easy and safer to eat, the kid can eat faster and can choose what to eat and when more easily. Similarly, having our engineers focused on cutting and cooking up small parts of a greater whole gives them the means of making a bigger impact more quickly for the team at large.
Stay tuned to this space for more upcoming blogs on our engineering journey, what it’s like to develop here, and, of course, more off-the-wall analogies like the above.
