Astrid Atkinson talks about what it means to manage distributed systems over long periods of time. She says she starts by thinking about the team, not the system. “Good teams and people are precious...building a good team is really difficult, a huge investment,” she notes. “Your job as an engineer is to make sure that adding scale doesn’t mean adding people.”
How orchestration differs from automation in the enterprise cloud.
The orchestration of workflow processes is an essential part of cloud computing. Without orchestration, many of the benefits and characteristics of cloud computing cannot be achieved at the price point that cloud services should be offered. Failure to automate as many processes as possible results in higher personnel labor costs, slower time to deliver the new service to customers, and ultimately higher cost with less reliability.
What is meant by automation? Automation is technique used in traditional data centers —and critical in a cloud environment — to install software or initiate other activities. Traditional IT administrators use sequential scripts to perform a series of tasks (e.g. software installation or configuration); however, this is now considered an antiquated technique in a modern cloud-based environment. Orchestration differs from automation in that it does not rely entirely on static sequential scripts but rather sophisticated workflows; multiple automated threads; query-based and if/then logic; object-oriented and topology workflows; and even the ability to back-out a series of automated commands if necessary.
Orchestration can best be explained through a typical use case example of a customer placing an order within their cloud service web-portal, and following the steps necessary to bring the service online. The actions below illustrate a very high level scenario where the cloud management software performs the orchestration:
Start exploring Kubernetes with minimal effort.
I had not looked at Kubernetes in over a month. It is a fast paced project so it is hard to keep up. If you have not looked at Kubernetes, it is roughly a cluster manager for containers. It takes a set of Docker hosts under management and schedules groups of containers in them. Kubernetes was open sourced by Google around June last year to bring all the Google knowledge of working with containers to us, a.k.a The people :) There are a lot of container schedulers or orchestrators if you wish out there, Citadel, Docker Swarm, Mesos with the Marathon framework, Cloud Foundry lattice etc. The Docker ecosystem is booming and our heads are spinning.
What I find very interesting with Kubernetes is the concept of replication controllers. Not only can you schedule groups of colocated containers together in a cluster, but you can also define replica sets. Say you have a container you want to scale up or down, you can define a replica controller and use it to resize the number of containers running. It is great for scaling when the load dictates it, but it is also great when you want to replace a container with a new image. Kubernetes also exposes a concept of services basically a way to expose a container application to all the hosts in your cluster as if it were running locally. Think the ambassador pattern of the early Docker days but on steroids.
Exploring the new Android M battery performance features.
It has been a long held personal belief that most battery drain issues on smartphone devices are due to applications that are improperly tuned. I work very closely with mobile developers to help optimize mobile apps for speed and battery life with AT&T’s own Application Resource Optimizer. I am also in the process of finishing up a book on High Performance Android Apps that will be published later this summer. So I am always excited to see mobile application performance hit the center stage.
Last month, Google held its annual Google I/O conference, where they announce new products, tools and features. This year, with the release of the Android M developer preview, performance of mobile devices/battery life and app performance were on the center stage (and unveiled at the keynote!). Lets look at the new features and tools available to users and developers to make Android’s battery life better.
Achieve performance goals in the face of compliance issues.
Download a free copy of Compliance at Speed, an O’Reilly report by Mark Lustig that breaks down the IT issues facing finance, healthcare, and other heavily regulated industries.
Today’s technology should work and perform without issues. When we build systems that work and perform, nobody pays attention; when they’re slow and unstable, everyone notices. This sentiment was no truer than during last year’s Healthcare.gov debacle. Building systems that work and meet our user’s expectations is always the number one priority.
Regardless of who we work for, the challenges of performance and DevOps are universal. There is one constraint larger companies seem to face more often — regulatory compliance. As privacy concerns have become more pervasive, compliance affects all of our companies in one way or another.
Reputation is based on trust. If I’m looking up my credit card balance and I end up seeing someone else’s information, I’ve lost trust in the credit card company, and they’ve lost a customer.
Large banks and health care organizations have been dealing with compliance for years, but every industry has constraints. Online retailers need to meet privacy and security standards. The social networking industry faces regulations specific to consumer protection and the use of customer information. No industry is immune to meeting compliance, as emerging regulations, both domestic and international, create more challenges to achieving performance objectives each year. Any website that uses, stores, or processes personal or payment information must address these challenges.
See your product's big picture and streamline experimentation with user story mapping.
Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by Jeff Patton from User Story Mapping, one of the selections included in the curated collection.
This is my friend Eric, standing in front of his backlog and task board in his team room. He’s a product owner working hard with his team to build a successful product, but right now it’s not. That doesn’t worry Eric, though. He has a strategy for making his product successful. And so far it’s working.
Eric works for a company called Liquidnet. Liquidnet is a global trading network for institutional investors. Long before Eric came to stand in front of the board in the picture, someone at his company identified a group of customers Liquidnet could serve better, along with a few ideas of how to do that. Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.
Why you should stop managing infrastructure and start really programming it.
Immutable infrastructure (II) provides stability, efficiency, and fidelity to your applications through automation and the use of successful patterns from programming. No rigorous or standardized definition of immutable infrastructure exists yet, but the basic idea is that you create and operate your infrastructure using the programming concept of immutability: once you instantiate something, you never change it. Instead, you replace it with another instance to make changes or ensure proper behavior.
Chad Fowler coined the term “immutable infrastructure” in a 2013 blog post, “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components,” but others have spoken about similar ideas. Martin Fowler described phoenix servers in 2012. Greg Orzell, James Carr, Kief Morris, and Ben Butler-Cole, to name a few, have contributed significant thought and work as well.
II requires full automation of your runtime environment. This is only possible in compute environments that have an API over all aspects of configuration and monitoring. Therefore, II can be fully realized only in true cloud environments. It is possible to realize some benefits of II with partial implementations, but the true benefits of efficiency and resiliency are realized with thorough implementation.