#Issue63
3 posts

Blue-green deployment: a microservices antipattern

Blue-green deployment is a technique that reduces downtime for your application by running two identical production environments called Blue & Green.
Read more

Blue-green deployment: a microservices antipattern

  • Blue-green deployment is a technique that reduces downtime for your application by running two identical production environments called Blue & Green.
  • At any time, one of the environments is live and one is idle. The live environment serves all production traffic. And your team deploys and tests in the idle environment. Once the new build runs fine, you switch the router to swap the live & idle environments.
  • Adopting this approach in case of microservices, tosses out the need for microservices to be independently deployable.
  • All microservices in a release need to be mutually compatible because the entire application is released in one go in the new environment.
  • “..this creates a distributed monolith whose pace of evolution is limited by the slowest-developing microservice.”

Full post here, 4 mins read

Security traps to avoid when migrating from a monolith to microservices

Rollback to the last known good state after a failure is more complex with microservices, so program in reverts carefully for data integrity.
Read more

Security traps to avoid when migrating from a monolith to microservices

  • Rollback to the last known good state after a failure is more complex with microservices, so program in reverts carefully for data integrity.
  • Move as many of your microservices as you can off the public networks to protect against DDoS attacks and other malicious actors.
  • Never pass data between services in plain text. Always encrypt.
  • Add monitoring to each service separately.
  • Develop a logging approach to follow for all teams, each service, consistently.
  • Don’t provide individual services too much access. Limit access intelligently based on need only.

Full post here, 7 mins read

Be as serverless as you can, but not more than that

Once you find what does deliver value, you can consider going partly serverless and investing more in the infrastructure for it.
Read more

Be as serverless as you can, but not more than that

  • As a startup that’s exploring what may work, you want to rapidly provide options to your customers and see how they respond without investing too much. Serverless architecture helps with this.
  • Once you find what does deliver value, you can consider going partly serverless and investing more in the infrastructure for it.
  • Ask how much of your stack you need to own to deliver business value and differentiation.
  • Consider whether it makes sense to outsource SLA, regulatory compliance, pricing and roadmaps to a service provider.
  • Optimize for cost and latency as you start to find predictable patterns for your new product or service.

Full post here, 5 mins read