This is strictly an opinionated guide to a handful of patterns and anti-patterns of designing Microservices boundaries. The motivation for this post came from my experience in the past few years working on different models of Microservices across projects at ThoughtWorks, and the ensuing heated debates on what constitutes a Microservice with fellow ThoughtWorkers. I sensed that more often than not, the boundaries are designed strictly based on domains, as in DDD. Now don’t get me wrong, domain driven boundaries are very important, but they are only one of the aspects and not the complete picture. I have seen microservices…
Pseudo random opinions on code quality and elegance that popped in my mind on a Sunday morning rumination in shower, before my morning tea. So pinch of salt and all.
The word API conjures up images of REST based HTTP URIs (or gRPC for the cooler kids) for most people. In this context I refer to API it at a much deeper sense. Treating any and every component (class, function, interface etc.) of a system as a user interface with helps reducing complexity. The users in this case are other programmers.
The interface’s sole responsibility is to provide the consumer…
There would hardly be a developer who would not know about StackOverflow
I remember my early programming days when Java Ranch was the go to place for any Java related programming queries. The community was prompt and welcoming. Stupid questions were OK.
But Java Ranch fell short on a couple of aspects:
The Radar is a document that sets out the changes that we at ThoughtWorks think are currently interesting in software development — things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists and is based on our day-to-day work and experiences (Source)
Disclaimer: This post is an opinionated distillation from the already opinionated Tech Radar. It does not reflect the views of my employer, ThoughtWorks.
I have deliberately divided the items in horizontal buckets rather than vertical ones. I won’t be describing…
TL;DR: Technical decision making in software projects is a challenging endeavour, especially if it’s being developed for someone else, viz. a customer or a product, and even more so if it’s a greenfield one. Technical aspects to consider for such a project are endless and often anxiety inducing. Below is an opinionated & pessimistic outlook on the topic.
Greenfield projects, or projects starting from scratch, or those that do not have a prior precedent, are unique in their appeal and challenges. Developers are drawn to such projects like moths to fire as there is immense learning potential. But there are…
The cloud computing festivities are on. After Microsoft, it’s Google’s turn, and finally to be followed by AWS re-invent in November. Google cloud next kicked off on April 9. Anyone who is even remotely DevOps would be interested in the event as a great opportunity to understand the new cloud offerings. As a technologist, I am excited about how the latest cloud tech can solve problems in my projects. The competition among cloud vendors is so cut-throat that the pace of innovation is breathtaking.
Here are some of the products I found nifty.
Google unveiled its Stadia game streaming service on March 19 to the excitement of gamers, streamers and game dev communities alike. In Google’s own words:
“Google Stadia is a new cloud gaming platform with its own controller. Stadia’s seamless cloud gaming platform offers tremendous scale, giving you the tools to push game development to new levels.”
If Stadia does what Google says it would, the above description is quite modest and abstracts the underlying mind boggling technical complexity. Here’s how it will work, let’s say you are watching a YouTube stream of a video game, and you find a particular…
Software engineering in general and programming in specific is a young person’s game; or so it’s treated. I have seen people’s quaint reactions (at least in India) for people coding in their 40s or 50s and even looked down if they still just ‘program’. But this is NOT a post about ageism in tech.
Programming is relatively easier to learn nowadays than it was a decade or two ago. There’s a galore of self-learned developers who excel at the craft, and competitive programmers who solve the most difficult problems in minutes. It is partly because programming is inherently a joyful…
Browser automation is quite a common requirement in software projects, usually intended to reduce manual effort of repetitive tasks. Typical use cases include:
1. Report Generation from a website’s UI.
2. Automation of common tasks without user intervention.
3. Robotic Process Automation or RPA.
There are many FOSS options to achieve robust browser automation, both in Headless & Headful manner. Tools including but not limited to:
Puppeteer with Chrome is the newest and the coolest kid on the block, while Selenium is the grandfather of all tools. …
Disclaimer: All opinions mentioned here are my own and do not necessarily reflect those of my employer.
I eagerly await each edition of the Radar to course correct my bearings as I navigate my way through the technology industry. It never ceases to amaze me the amount of work put in by the creators of the Radar (of course I am biased as a ThoughtWorker). This also makes the Radar…