At Flux7, we are passionate about sharing the power of DevOps. In that vein, we recently gave a workshop introducing developers to the power, ease of use, and governance that comes with moving to a DevOps model reinforced with well-architected tooling. The goal of the workshop was to teach developers more about AWS and Docker-based microservices architecture. And, how using Amazon services like EC2 Container Service, CodePipeline, and CodeBuild can come together to create a platform for developer teams to focus on their application. We highlighted the Anchore solution as part of our microservices architecture for security and will share in today’s blog why we deployed Anchore, how we used it to ensure DevOps security and policy compliance, and our overall experience with the tool.
Join us Thursday, August 24th in Austin, TX for a dynamic one-day microservices architecture and Amazon ECS workshop session.
Continuing with our recent theme of Flux7’s DevOps approach and best practices, today we will discuss the Flux7 microservices philosophy. While we’ve previously defined microservices and their benefits, we are taking a step back today to look at the bigger picture and how one might view and approach microservices for best results.
While microservices benefit a variety of organizations on multiple fronts, (for a deeper discussion on this, please check out our blog, “Microservices Trend as IT Competes on their Respective Strengths”) today we are examining how one startup used a microservice architecture to give developers greater agility and add automation to gain a competitive advantage in its industry.
To support the business as best as possible, it’s important for Development to issue new features -- or greenfield solutions -- to market as quickly as possible. It’s not a stretch to say that many organizations’ ability to compete successfully depends on their speedy delivery of new products to customer. And in some cases first mover status is the difference between owning a market or bowing out of one.
AWS recently announced that Amazon ECS now supports a state for container instances that can be used to drain a container instance in preparation for maintenance or cluster scale down. AWS reports that the draining state prevents new tasks from being started on the container instance and notifies the service scheduler to move tasks that are running on the instance to other instances in the cluster. This is great news that we expect to save a lot of time and scripting when it comes to updating or removing containers from a cluster.
Amazon announced its Elastic Container Service (ECS) at re:Invent 2014 using Pristine as a case study. Given Flux7’s Amazon expertise, it’s likely no surprise to frequent readers of this blog that Pristine is a Flux7 customer who we have been working with for some time now.