Location: Auckland, New Zealand
Remote: Yes
Willing to relocate: Yes to Europe
Technologies: React, JavaScript, TypeScript
Résumé/CV: danewilson.me
Email: danew@danewilson.me
How can you have a chance against WebStorm by not being the biggest editor?
WebStorm is IntelliJ Idea. It’s a full IDE with capabilities beyond that of a simple code editor: code analysis (for multiple languages), smart refactoring (for multiple languages), extensive plugin support, an extensive range of support for anything from eslint configs to understanding things like “oh, it’s an Angular app, let me help you connect all the pieces together”, etc. etc.
I assume the "set of specifications" is normally provided via some sort of project tracking software like Jira. A problem with this is these specifications get lost in history, not to mention become outdated as the features evolve.
From my experience having well a documented code base allows you to understand decisions at a later date, especially when key members have left the company.
That works well in your current situation, but when you have multiple products and services that also need to send emails it makes sense to combine them into a single service.
Microservices solve a number of engineers scale problem, not a traffic scale problem. Tech scale is drastically more simple in a single application, because you don’t introduce an unreliable network and related complexity into all of your problems
Interesting, in my experience we've never had major issues with our service mesh or internal networking. It definitely introduces a lot more complexities. I suppose we've always had a dedicated devops team so I'm probably unaware of a lot of these issues.
I'd be interested in some resources around this topic if you know of any.
I'll be honest - pretty hard to find objective literature on it, because most of the literature is just trying to tell you microservices will solve all of your problems. I think ultimately the best link between the two is Amazon's move to microservices and their focus on "2 pizza teams".
The ClusterIP and LoadBalancer are on separate network interfaces.
The ClusterIP exposes the service on an internal interface whereas, the LoadBalancer exposes on a public interface.
Domain driven design from Eric Evans is a great resource for learning about how/where to separate out services.
You will learn about how to model complex domain models and how to decompose them into Aggregate's. The Aggregate is the key to where to create new microservices, as each aggregate should only contain domain objects that relate to itself.
I'd say a bounded context is a better border. When doing REST you can then begin by implementing each of your aggregate roots within the context as a resource.
