I’ve been pairing for over a decade. I’ve witnessed and tried all kinds of things shoulder-to-shoulder with all kinds of pairing partners. Through the years I’ve witnessed a single consistent misfire while pairing. We don’t understand our roles. As professional problem solvers we gravitate towards actively solving the problem at hand.
In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
In a previous article we discussed some of the positive characteristics of microservices that we’ve found while implementing them in a production setting. Two of the primary benefits we discussed are the architectural agility and enforcement of api boundaries. While you may find those and many more benefits from using microservices, you will also find that the positives don’t come for free. In this article, we’ll discuss some of the challenges that we’ve dealt with in implementing a microservice-based architecture. Being aware of these will save you the time and frustration that we experienced early on in our experience with micro services!
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
A recent topic grabbing the stage in the software community is the use of Microservice Architectures. Microservice architectures are often sold as a great way to enhance a project’s agility over a standard, monolithic architecture. While this can certainly be the case, and there are indeed many benefits from using microservices, the use of a microservice architecture also brings about many unwritten challenges to the way software is designed, developed, and put into production. In this article, we will lay out some of the positive characteristics specific to using microservices that we’ve found while implementing them in a production setting.
Source Allies is a technical consultancy proudly working with clients in Des Moines. We focus on application development, and trend towards newer technologies. Our strength lies in our people: talented, intelligent, and able to handle challenges in a professional manner. Our hope has always been to have a positive impact on our local community, and this blog will focus on our plan to do just that!
Amazon just announced general availability of their Elastic Container Service providing a platform for launching Docker images in the cloud. Let’s say your team is developing software on Windows and Mac OSX, but Docker requires the Linux kernel’s virtualization features to work. By now, you have likely discovered that Vagrant and/or boot2docker provide nice ways to run Linux on your local PC or Mac and provide a docker deployment platform.
But with so many different options available to configure how your Docker containers talk to each other, how do you get started? In this article, we will take a look at a basic set of containers needed to stand up your own Docker registry (a must if you want to share your images in a place other than the public docker.io or paid private quay.io) and look at four different ways to launch your containers: