In 2013 Gene Kim, Kevin Behr and George Spafford published The Phoenix Project, a book that marries the concepts of manufacturing agility from Eliyahu Goldratt’s The Goal and relates them to IT. As they elucidate in the story, a new approach to IT is clearly needed and many organizations are embracing that change through the DevOps methodology. However, DevOps can be a very broad term making it difficult for people to know where to begin. As a result, we have narrowed the DevOps model
A misconfigured data bucket in AWS Simple Storage Service (S3) led to a Republican contractor’s database of nearly every voter being left exposed on the Internet for 12 days, according to CRN. This news presents an unfortunate reminder of why good AWS security hygiene is important to designing, building and managing AWS environments. In this spirit, we’d like to explore two basic AWS best practices that when built-in can help stave off extreme events like this.
High availability has become a key requirement of every layer in today’s technology stack. And, message queuing or message brokering software is no exception. In the past we’ve relied, like many of you, on RabbitMQ to create highly available message queues when FIFO (First-In, First-Out) was required. (Indeed, our RabbitMQ tutorial is one of our most-oft read blogs.) Often this is for ecommerce, financial services and other applications where it is important to strictly process messages only once and in the order they are published.
Berry Christ, Chef CEO predicted at Chef Conference 2017 that Web and mobile will eventually become table stakes, the lowest bar to market entry. Taking his prediction one step further, we see a day where DevOps will be the minimum entry requirement needed to become and remain market competitive. That may sound aggressive given the fact that only 20% of businesses have adopted DevOps, according to research last October by Gartner. Yet, for organizations that have implemented DevOps, 66% saw faster realization of business value. And, according to McKinsey, firms with high performing IT organizations were twice as likely to exceed their profitability, market share, and productivity goals.
At the recent Austin DevOps Days Conference, Flux7 CEO Aater Suleman gave a talk on the "Top Ten Considerations When Planning Docker-based Microservices”. For those of you unable to attend the conference, you can listen to a replay of the presentation here. Or, read on as we share part of his talk focused on the synergy between DevOps, Docker and building microservices.
Flux7 DevOps consultants have worked with more than 150 companies over the years as they have gone through the DevOps transformation process. And, we’ve learned a lot along the way, including the patterns that emerge in the DevOps journey and where most people land and/or have the vision to land. We’d like to share that journey with you today and more importantly, how we’d encourage you to think about the DevOps framework that helps gets your organization there.
AWS automation recently got a boost: the company introduced the ability to build an end-to-end release automation workflow that can deploy changes across multiple regions or different AWS accounts. And they subsequently featured an article on their blog on the steps to create a cross region CodePipeline. Today, however, we want to address the other half of this equation -- building cross account pipelines -- and thought it worthwhile to share with you here when and why we would recommend the benefits of this approach.
Where does code end and configuration begin? It’s a perennial question. And, as the lines continue to blur between the two we here at Flux7 have begun defining new terminology and ways of thinking of the issue that we’d like to propose in our blog today. As part of a community of developers whose work often entrenches them in these issues, we greatly appreciate your feedback and help in fine-tuning these definitions for the betterment of our collective work.
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.