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.
Authored by: Trevor Richardson & Todd Brunia
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.
Wikipedia defines DevOps as:
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.
Motivated by the introduction of Lambdas in Java 8, I wrote a couple of examples to see how difficult it would be to follow a functional programming paradigm in real production code.
Latest posts by Ghaith Alrabadi (see all)
- Java 8: Parallel vs Sequential Stream Comparison - September 23, 2015
- How to implement the splitter and aggregator patterns with Apache Camel - January 19, 2014
- Iterators, Functors and Predicates - August 24, 2012
I will demonstrate using some features from Java 8 with a simple and fun example.
About a month ago, I facilitated the first event as part of the Source Allies external mentoring program known as Source Allies University (SAU).
It was an interactive forum and networking event designed to:
- Cover basics and explore new tricks of Test Driven Development (TDD) in Java
- Create new code & refactor existing legacy code via TDD
- Code through a sample project for hands-on experience
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:
Latest posts by Matt Vincent (see all)
- 4 Ways to Launch Docker Containers - May 14, 2015
- Aggregate MyBatis.NET SqlMaps from Multiple C# Projects - October 6, 2010
- The Easiest Way to Organize Zimbra Email - February 26, 2010
Your hard drive with very important family pictures has just failed, and now all data is lost forever. Could you have prevented this from happening? This article is a quick walk though of how to detect hard drive errors before the disk is unusable.