Just five years ago, most enterprises operated their innovation efforts in silos. Development was in one corner, working on the next big thing; operations was in the other, making sure that none of the technology stopped working. Far too often, like Star Trek’s Dr. McCoy, people in these disparate roles exclaimed, “I’m a doctor, not a ...” They rarely engaged with each other—and things were left to fall through the cracks.
This blog post is a step by step tutorial on how to set up PostgreSQL Replication between AWS regions. This is an essential part of our disaster recovery plan at Engine Yard. A previous blog post gives a higher level overview on disaster recovery.
This blog post is a step by step tutorial on how to set up MySQL Replication between AWS regions. This is an essential part of our disaster recovery plan at Engine Yard. A previous blog post gives a higher level overview on disaster recovery.
Expanding your DevOps team can sometimes feel like defeating a demogorgon—or demodogs for that matter (R.I.P., Dart)—without Eleven. You may have a paladin, a cleric, a bard, and a ranger. But without the mage, or at least a little truesight, it’s tough to know how to make the most of your resources and expand your capabilities. (Can you tell we’ve binged on Stranger Things 2?)
What Is DevOps? The million-dollar question, it is. Much like the trailer for “Star Wars: The Last Jedi,” it seems like everyone is talking about DevOps. It has made waves in the technical community, bringing with it promises of increased development speed and business agility. And while we can’t really tell you what’s up with the melodramatic shots of Mark Hamill in the trailer (okay, we’ll stop it for now), we can confidently say that the benefits of DevOps are contingent on a business’ ability to both understand and implement certain concepts across the organization.