To be an engineering manager, or a software development manager is a decision you make at some moment of your career. It's not an immutable decision and I'm pretty sure that the majority of software managers from time to time, entry to senior levels, think about returning to the technical path.
That’s totally normal: you were a software engineer some time before, it's your background. Code was your first passion in the software world.
In my point of view, the motivations that made you an engineering manager are one of below:
Cassandra is my favorite (not managed) database for many reasons: it doesn’t have a single point of failure (SPoF), supports multi-region, good for read and write ops, flexible about read and write consistency levels, scales linearly and not too complex to manage for day-to-day operations.
Like every database, you should use Cassandra based on your data access patterns, so if you need a flexible database for ad-hoc queries or adaptable enough for constantly database model changes, you should consider other options.
Cassandra is a column-oriented DB and it’s really powerful when you have your data queries already defined. Datastax, the company that supports Cassandra, recommends you should start by designing your queries and then your data model in Cassandra. Despite the fact of your columnar structure, Cassandra support many data structures as a column(s) type, such as Maps. …
As an API owner, you must consider not only the good design of your APIs, but the non-functional aspects as well.
Think about a bank, it could be the easiest one to make a transfer or pay a bill, but if it is not secure and safe you’re not going to use this bank anymore. This same rules applies for API providers.
Safety in this context means that your API (Microservice) is protected from misuse and security means that your data is protected from malicious activities.
One of the ways to bring safety to your API ecosystem is by using Throttling policies. For creating a security platform not only for API providers, but also for API consumers, you should consider to implement an authentication process. …
Microservices is a new trend in software development which many organizations around the world are adopting (and counting…). From e-commerce websites, to social network platforms, everybody is talking about this new way to design software architectures. If you have premises like scalability and high availability or if you want to reorganize your teams around business capabilities, this new approach can help you. A lot.
Recently, in the last re:Invent (2017), AWS launched a new service called Fargate, which can simple be described as an abstraction to deploy applications through containers.
AWS already had a service to manage containers, called Amazon Elastic Container Service (ECS), but ECS is more connected with the infra-structure layer than with the application layer.
The main idea behind Fargate is that you only have to think about the computational footprint of your application, memory and CPU, and it will manage all the other stuff for you automatically.
In B2W, we have many environments where we run our Microservices. One of these environments is AWS, and we deploy our applications using Elastic Beanstalk. Another environment is managed by us, and to simplify our operation, B2W’s DevOps team built an abstraction that uses Mesos and other Mesos frameworks. The concept of Mesos is to provide a unified vision of your infrastructure and their compute resources, so you can organize all of those resources through Cluster(s). …
There are many reasons and benefits related to opt for an architecture based on Microservices, but there is no free lunch, at the same time it also brings some difficult and hard aspects to deal with.
At B2W, we started to work with Microservices in 2014 and motivation behind was related to stability and consequently to scalability aspects. Since that, 3 years passed and currently we have hundreds, or maybe a thousand Microservices running in production.
As we're in a good level of maturity, the idea behind this serie is to share some lessons learned about this process.
Below, some best practices related about Microservices communication that you will find useful. …
One of the hottest topics in the technology world is BIG DATA. And it makes sense.
I’ve been living this reality so close with my teams and I’d like to share a little bit about our experience. Why did we start to talk about this? Where do we started? Which effects we are living? Where we want to go?
We changed our architecture three years ago to use microservices and at that time, the motivation was purely technical because we had to scale our applications for high throughputs. …