Continuous Delivery (CD) is a core facet of successful DevOps and as a result, a core Flux7 strategy for implementing DevOps-based IT modernization. At Flux7, we always view DevOps as streamlining the delivery of not just Code but also the delivery of Infrastructure (networking, firewalls, VMs), Server Configuration (software packages such as Apache or JAVA), and Security Rules (policies for AWS Config Rules or HashiCorp Vault). Among these, efficient delivery of infrastructure and configuration are both very critical for full stack agility. For our customers in AWS, our typical choice for infrastructure delivery is CloudFormation. We like AWS CloudFormation because it is native to AWS, follows a simple YAML or JSON syntax, and has deep integration with other AWS Services such as the AWS Service Catalog.
In our last article , we took a look at why Docker is a natural fit for microservices and the top five process design points to consider when planning for a Docker-based microservices deployment. Today we will dive into the top five technology design points that should be considered in the planning stages. Doing so will help you avoid potential stumbling blocks that when not thought through in advance can really cause headaches down the road.
As AWS consultants steeped in DevOps best practices, Docker, and the forward edge of new technologies and architectures, we often get asked about microservices. One of the most common questions we field is around potential stumbling blocks to a Docker-based microservices approach. This is a really smart question as there are several considerations that when not thought through in advance can really cause headaches down the road.
Before we talk through these top considerations, however, let’s first review why so many organizations are considering microservices in the first place. As you likely know, the idea behind microservices is that instead of writing an application as a single monolithic code base, developers can break it into smaller, autonomous services. This allows for more agility and greater autonomy amongst different teams, allowing them to work in parallel accomplishing more in less time.
In our blog last week we told you that AWS CloudFormation has grown its support beyond JSON to include YAML. Prior to the announcement, our AWS consultants had been writing in YAML and used an in-house YAML CloudFormation generator to help us avoid the typical pain points associated with JSON. We promised in that article to share with you instructions on how to convert existing JSON CloudFormation templates into YAML and are delivering on that promise today.
As we discussed recently, AWS microservices are being adopted widely across organizations and industries for their ability to increase service delivery and speed time to market while decreasing team overhead. As organizations begin traveling down the path to a microservices architecture, one hurdle that they often run into is enterprise password management or secret management. For, as the number of microservices increase, so too do the number of credentials—often exponentially so—creating a need for effective and efficient management.
As DevOps consultants, at Flux7 we believe that Continuous Delivery (CD) is a key tenet of successful DevOps. And as heavy users of Amazon Web Services (AWS), we have a keen interest in any tools or features that streamline CD for our clients within AWS. For this reason, we are pretty excited to dive into the Amazon Pipeline Starter Kit. Now, you may be familiar with two services that Amazon has traditionally offered to help facilitate CD: AWS CodePipeline and AWS CodeDeploy.
Pundits have declared that 2016 is the year microservices graduate from early adopter to early mainstream adoption. The aggregate predictions are certainly right if the call volume here at Flux7 is any indication. We’ve been seeing this trend in full force as we field call after call from organizations across industries, from enterprises to startups, all looking for advice and expertise in building their own microservices architecture.
Service discovery is not new. The idea of a tool that can discover how processes and services talk to each other and help facilitate connections has been around for some time. However, with the rise of increasingly dynamic environments, the important role service discovery plays continues to grow. Indeed, since the beginning of the year at Flux7 we have seen a surge of customers looking for container-based microservices architectures that highlights the need for service discovery due to its dynamic nature.
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.
As AWS experts we work closely with organizations who handle a wide variety of sensitive information – from patient health records to credit card data and more. Resultantly, we are always on the look-out for technology and best practice-based improvements to ensuring cloud-based security. With more and more of our clients looking to embrace a microservices architecture, cloud security and compliance naturally didn’t stop being a focus which is why we are happy at the news from AWS today that they’ve addressed how to help secure container-enabled applications with IAM Roles for ECS tasks.