Configuration Management, as applied in DevOps, is the practice of using tools to manage the configuration of our technical architecture. Put simply, we document the desired state of one or more servers in a machine-readable form, and then use a configuration management tool (e.g. Chef, Puppet, Salt, or Ansible) to setup the real items to match the configuration.
Why? As with many things, you might think “I barely have time to setup this server manually, never mind write a script for it”. But the reality is, in today’s world, we’re probably going to have to do the same setup multiple times. In enterprise environments, the software engineering process will require deployment to several environments (development, integration test, user acceptance test, performance test, then finally production). It’s critical that all these environments are identical (so far as is practical). This is a key tenet of DevOps operating practices – we can’t apply learnings from one environment to others if the environments are different. Even in a simpler environment, you’re probably going to replace your servers in a fairly short time frame.
Once upon a time, we used to buy server hardware and nurse it along for years. Nowadays, hardware and system software ends up obsolete in a matter of months, not years. If you’ve done your CM work properly, it’s faster to deploy to a fresh OS image than to patch an existing image. And if you’ve embraced virtualization or a cloud environment, you’ll find it’s easier to replace a server than to troubleshoot it.
There’s another advantage to Configuration Management: The system state is documented and version controlled. There’s no need to do archaeological work to find out what your technical architecture has evolved to – you just look at the configuration scripts.
So here’s your challenge for the next year: Stop managing your servers by hand. Setup an open-source Configuration Management system and create a configuration repository (I’m partial to Ansible. See http://www.webagesolutions.com/knowledgebase/kb024/kb024-install-sw-ansible.html for some tips to get started). Every time you find yourself ssh-ing or logging in to a server, stop yourself and create a playbook, recipe, or run-list in your CM repository. Make it a habit to use manual tools only to examine the server state, not to change anything. Run your servers the way developers write code: If it isn’t in version control, it didn’t happen!
For that matter, do the same thing on your laptop or workstation. You’ll soon find that you’re much less stressed about maintaining your configuration or upgrading your hardware.
LinuX Containers (LXC) is an OS-level virtualization that allows multiple Linux systems to run on a single physical machine in a multi-tenant arrangement. This type of virtualization is extremely lightweight with every virtual machine (container) being mapped into the booted host OS obviating the need to boot from their own OS image; all the needed resources of the host machine — CPU, the filesystem, system libraries, network access, etc. — are received by containers on a shared basis. Basically, LXC re-uses the same single kernel of the host machine for all hosted containers.
Read the rest of this entry »
The webinar today was a huge success. We had about 300 attendees. There were many excellent questions.
You can download the presentation and sample code from this link.
Links to useful resources:
Clearly as an employee of a company that makes a lot of it’s business on training and consulting for Java programming and technologies this is not a pleasant thought to entertain. It also seems like a fairly somber topic for my first post to our company blog. Unfortunately this is a question I’ve been asking myself over the past few years (as really anyone who works with technology should ask) and lately I’m a little more concerned about the possible answers and factors that allow you to arrive at those answers.
First, I think a little bit of history about why this has concerned me of late…
Back even before Sun was swallowed by Oracle I was commenting internally on a situation that was developing that I was somewhat concerned about. The situation was a dispute between Sun and Apache around the efforts of Apache to create an open-source implementation of Java SE, Apache Harmony.
I won’t get into too many details but it basically came down to the fact that the Apache Harmony project was unable to get a copy of the “Java Compatibility Kit” or “JCK” which would be used to certify that the Apache Harmony implementation is fully compliant with the Java SE specification (a good description of the problem is available on Stephen Colebourne’s blog). Sun was willing to provide Apache Harmony with a copy of the JCK but it’s license placed “field of use” restrictions on what users of Apache Harmony could use Harmony on. Since the people at Apache are very serious about licensing and open source software they argued that Sun was basically violating the rules that they themselves set out for the Java Community Process (JCP) which stated that the lead of a JCP specification could not place any contractual restriction on the right of a licensee (in this case Harmony) to create or distribute independent implementations.
The entire issue Apache was correctly pointing out was that nobody was going to be able to create independent implementations of Java SE (and therefore just about anything Java) without accepting these limits that they would need to pass along to users of their implementation.
If it were just Apache that held this view it may not have had much impact because the JCP works with specifications by allowing members that are part of the various “Executive Committees” (currently Java ME and Java SE/EE) to vote on Java Specification Requests (JSRs) that are proposed to create Java specifications. Since the JSR process is one of the things that makes the Java community so vibrant this is obviously an important process.
As this issue developed it was clear from the minutes of the JCP Executive Committees that the other EC members recognized this dispute was about more than just Sun v. Harmony and had broader implications. In fact, it was pretty clear from the minutes that there was broad agreement with Apache from most EC members, including Oracle (pre takeover), that this dispute needed to be resolved and that Sun didn’t have many friends that were seeing it’s side.
It had gotten so bad recently that on the recent Java EE 6 public review ballot, Apache actually voted no because it felt Sun was violating the agreements of the JCP and many other members of the Java SE/EE executive committee expressed concern about the issue, although only Apache voted no.
In fact the US Department of Justice extended it’s period for reviewing proposed acquisitions for the Oracle acquisition of Sun apparently specifically to investigate the Java licensing issue. Unfortunately it was not apparent publically that the issue was resolved or any closer to resolution before the merger completed.
This matters for the broader Java community because this issue will probably come to a head over Java SE 7. Java SE 7 “features” are being developed in OpenJDK right now but there is no specification proposal. OpenJDK is the “open source implementation of Java that we control” started by Sun and now Oracle. Even though the argument could be made that OpenJDK is an “independent implementation” of Java SE it also allows Oracle to release the OpenJDK implementation as the official Java SE JSR implementation where they could reintroduce the restrictions on the compatibility kit.
Sun and now Oracle have not yet submitted any JSR for Java SE 7. Based on the comments of many Java JCP board member companies on recent specifications like Java EE 6 I get the feeling that the Java SE 7 spec would actually be voted down if Oracle would not allow open source implementations to license the Java Compatibility Kit and therefore be “certified” without the restrictions. This of course would make headlines nobody involved with Java would want.
Now enter Google and Android…
The Android platform from Google is based on a subset of Apache Harmony recompiled into the “Dalvik” VM for mobile devices. This provides support for Android applications to be written in Java but obviously does not go the route of Java ME (Mobile Edition) which is of course the “official way” Android could have done it. This has resulted in Oracle suing Google in a case that could have the same implications for the Java community that Sun v. Microsoft did.
The unfortunate thing about the lawsuit is that according to some the Apache and Oracle camps may have been working recently to “finally certify Harmony with Oracle”. Even though no resolution was made it was promising that this was still an active issue. One has to wonder where the lawsuit puts the process of certifying Harmony. What is interesting from the article link above is that Apache seemed to agree with Oracle that the actions taken by Google would threaten to fracture the Java community.
This would be unfortunate because mobile smartphones really have the promise to expand the reach of Java all over which was always the goal of Java but just now becoming the reality.
The Oracle v Google lawsuit itself is based around software patents and not directly the licensing issues of Harmony and Java SE. I think this is more because Oracle feels that a lawsuit about patent infringement would be easier to try in court unlike the confusing maze of licensing issues from directly challenging Android using an unlicensed Harmony.
I won’t really comment much on the lawsuit itself because there are certainly lots of other opinions out there. Some are touting it as the “final showdown” between software patents and open source. Some feel that Oracle is simply trying to capitalize financially from acquiring Sun and Java. Others are glad that Oracle is stepping up to defend Java. James Gosling (creator of Java) also has some interesting thoughts although it seems like it is mostly “I could see this coming” when he was still working at Oracle before leaving recently.
I think I am somewhere in the middle. I don’t think Google is totally faultless as it seems like they were just begging to get sued by the approach they took. I also think that even if Oracle doesn’t get entirely what they want part of what they might have wanted to accomplish is to create uncertainty about the Android platform, which they certainly have done.
So finally, back to our original question, will Java be around in five years?…
After the Oracle v. Google lawsuit got me thinking more about this again some research caused some concerns and reassurances.
At first I was concerned with the fact that if you look at the summary of JCP JSRs by stage there are no JSRs in the early stages of proposal or early review. Some research shows however that the number of JSRs has been declining for some time, probably due to a number of factors although the battle of Java licensing certainly has to be one of those factors. Of course there did seem to be a steady-state of JSR work from 2004-2006 and since the Sun/Apache issue started 2005-2006 it could also be argued that it was part of the JSR decline.
It is clear that the JCP process itself is likely going to have some major changes. There are notes in the May 2010 JCP EC minutes that the EC discussed the proposed future of the JCP process by Oracle although the discussion was a “private session” with no details except the general topic and the July 2010 minutes are not yet published. Unfortunately I’m not sure that the Google lawsuit exactly bodes well for the possible future of what the JCP will be.
I’m also concerned that even though Java retains it’s spot as the most popular programming language there was significant downward movement since last July and Java only barely held on the top spot compared to C. Certainly a headline of “Java is no longer the most popular language” is not the kind of headline that would help after the lawsuit and right about the time that JavaOne will convene for the first time under Oracle.
I think overall Java will be around in five years as too many companies, including Oracle itself, have too many products based on Java. It is more just a question of what kind of shape it might be in. The next few years will actually probably be on fire as the Java EE 6 specification is a great step forward in the simplification and power of Java much like Java EE 5 was. We are also going to see many major vendors implementing Java EE 6 much faster than they did with Java EE 5 which will be good.
We will have to see if the statement “Oracle supports open source” is just lip service meant to buy time to retain complete ownership of Java.
I think this is something important to follow because it might throw a hiccup into the Java maturation process at exactly the time many companies are taking a second look at Java. Hearing that there are “license disputes” that are preventing the Java specifications from moving forward would certainly throw some cold water on any plans to move to Java after previously deciding against it.
Hopefully those reading this that may not have been aware of the issues and how there is an underlying thread among many of these developments have benefited from getting quickly up to speed. I think there will hopefully be quite a bit of information about many of these issues at the JavaOne conference in mid-September. Stay tuned here for what I think everyone will agree is hoped to be good news on this front after a summer of some troubling news.
Java and Administration Lead
Web Age Solutions
Here is some useful information if you want more info:
Apache statement on the Sun/Apache dispute – http://www.apache.org/jcp/sunopenletter.html
History on the original Sun/Apache dispute (Stephen Colebourne’s blog) – http://www.jroller.com/scolebourne/entry/shedding_new_light_on_no
An article on the issue between Google Android and Oracle (pre-lawsuit) – http://www.theregister.co.uk/2010/06/09/harmony_android_oracle_apache/
JCP Executive Committee minutes – http://jcp.org/en/resources/EC_summaries