Is your growth being stifled by your current company? Time to find a place where you can assume new responsibilities and pickup new technical skills.

If you have the feeling that you cannot grow in your current job, it’s time to move on. Staying put not only means getting sidelined and frustrated, but even worse, your technical skills will become crusty and outdated. Put the fun back into working and learning in an environment which challenges you and values your contribution.

The Environment

At gutefrage.net, you’ll find a challenging and open environment which puts you back in the driver’s seat of your own growth. You’ll build and run web applications scaling to millions of users while earning real money!

The Tools

We at gutefrage.net believe in the value of experience, and know that a seasoned Web Application Engineer can thrive in any language or web framework. We’re currently looking for support in growing our Ruby On Rails based portals. If you’re fluent in any modern web application framework (like Zend, Django, or even Ruby On Rails), Test Driven Development is second nature, and you know your way around a Linux box (maybe even using configuration management tools, preferably Chef), we should talk.

The Location

gutefrage.net is located in the center of Munich, Germany and belongs to the well established Georg von Holtzbrinck publishing group, which is active in more than 80 countries.

Contact Us!

If you want to help expand our well established and fast growing web sites www.pointoo.de or www.helpster.de, please contact us right away. Either send me a DM @mmarschall or use the offical route by mailing to jobs@gutefrage.net. Of course, we’ll keep your inquiry confidential – no one should get hurt.

I’m looking forward to hearing from you!

See, what we build:
www.pointoo.de
www.helpster.de

Find out what your future colleagues are writing about:
Blogs: www.agileweboperations.com and www.nistu.de
Follow us on Twitter: @mmarschall, @nistude

Other posts:

• How to Deploy Ruby on Rails With The Opscode Chef Application Cookbook
• Aegis: Role-based Permissions for your Ruby on Rails application
• Setting up a test database on a ruby on rails continuous integration server using SQL instead of schema.rb

That tiny, little detail is a collection of inefficiencies you’ve introduced over time. On a dedicated, big iron server, it doesn’t really hurt if a database query takes 0.2 sec. And you didn’t care that the very same query took 2s on your local development box, because you knew it would be “fast enough” (™) on the live site. Well, you’re right…right up to the point where your application has to scale, when you’ve got enough users on the system that even your “big iron” begins to cough and sputter.

Scale-up is not an option if you’re already using top-of-the line hardware

If you’re already running the biggest server available, it’s really hard to scale that box up. So, your remaining options are:

• Scale-out to other servers
• Optimize your code

Both options are tedious – especially if your site is under heavy fire. It would be so nice to just upgrade to a bigger server and buy yourself a couple of weeks to optimize your app and prepare for scaling.

Avoiding over-capacity

One way to avoid crashing into such a road-block is to run your application on smaller hardware from day one. Even if you’ve got big iron available, it’s a good idea to put your web app inside a virtual machine, limiting its resources. By doing this, you’ll get early warnings of scalability issues. If you write a query which takes too long, you’ll notice on the same day. If your application gets a load spike, you have some breathing room to scale it up while you’re preparing the scale-out architecture. Working with constrained resources is a good thing because it forces you to do a better job right from the start!

No related posts.

After DevOps Borat and BroOps it’s time for The DevOps Dudes!

Click through to see it full size

Other posts:

• DevOps is NOT a Job Description
• DevOps: Why Silos Suck And How To Break Them
• Do you have a DevOps Culture?

Wonderlane

The DevOps hype produces some strange effects. Not only do tool vendors try to jump on the DevOps band wagon by declaring their products “DevOps inside” or listing DevOps as a feature, but companies start to look for a “DevOp” in their job ads. Don’t be misled! Here’s what DevOps is really about:

DevOps Is About Culture

The fundamental basis for successful DevOps is a culture of trust and a feeling of fellowship. Everything starts with how people perceive each other: Is it an “us vs them” culture or is it a “we”-culture? I don’t see any job description in here.

DevOps Is About Automation

Let’s look into automation. A lot of the advantages DevOps promises lies in the right use of automation tools. Automation removes variance from your processes and minimizes human error. While you’ll definitely need people with automation skills and experiences, this is not enough. Automation only – without the right culture – will not provide the benefits you hoped for.

DevOps Is About Measuring

Then let’s examine measuring. While measuring is a critical, mandatory practice for improving processes, it’s not really a job description. Every employee should formulate hypotheses, run experiments, and validate or scrap her ideas. No magic sauce here either.

DevOps Is About Sharing

What about sharing? I’m sorry to say that while the DevOps movement is largely driven by sharing ideas, problems, and tools, this isn’t really a good job description. It is an attitude more than a task.

If you run through the points, which really define DevOps you’ll see for yourself how strange it is to try and hire a “DevOp”. DevOps is not a job – DevOps is Culture, Automation, Measurement, and Sharing (CAMS).

Other posts:

• Do you have a DevOps Culture?
• 2011: Time to Escape the DevOps Echo Chamber
• DevOps: Why Silos Suck And How To Break Them

| spoon |

Dev and Ops are separate departments

Organizations typically divide their teams by type of work. They create development departments for writing software. And, because running software quickly and stably requires a different set of specialization, they create a separate operations department. This division of labor simplifies management because each department shares certain characteristics and needs.

Separated departments have conflicting goals

Each department defines goals along division of labor lines. The development department may be measured by the speed of creating new features, while operations is judged by uptime and response time. Unfortunately, operations is considered successful with stable, unchanging metrics, but development is only applauded when lots of things change. Conflict is baked into this system making collaboration unlikely.

Dev and Ops sub-optimize to meet local goals

Instead of optimizing the whole application lifecycle, both Dev and Ops improve their processes to meet their respective goals. Developers do everything to speed up the creation of new features by adopting agile methodologies. Sysadmins do everything to maintain stability and enhance performance by applying ITIL which equates change to risk – something to be avoided at all costs.

In an even crueler twist of fate, when each of these departments are operating at maximum efficiency, the product lifecycle suffers the most. Development is continuously pounding out new features against the walls of Operations which, in turn, has all kinds of defense mechanisms in place to fight change. A huge war is about to break out, and the only way to avoid it is by aligning the goals of these two departments.

Other posts:

• DevOps: Why Silos Suck And How To Break Them
• The 5 Goals Of Agile And DevOps
• DevOps Q&A with Kevin Parker

rmlowe

No matter how small and insignificant you might be, you can still be a catalyst of powerful change. An idea may give somebody the “Aha!” moment which, in a heartbeat, literally changes their entire outlook on life. They impart this change upon others and the process reverberates outwards – babbling brooks forming streams.

Telling a developer about the importance of automated testing is a mandatory, minimum requirement of being a software development manager. Kinda like grade school. You learn how to read, write and do basic arithmetic. Maybe you can even remember a favorite teacher, but the rest is a blank.

Showing a developer the ease of automated testing might get a spark started – TDD can become infectious if done right. You’re implementing learned knowledge (and, more importantly, how to cut corners and save precious time for other activities). And, this, unfortunately, is about the highest level most folks ever reach. They survived the manager from hell that forced them to write tests and improve code coverage without really understanding the underlying principles.

You must convince developers that code quality is their responsibility. Such an idea is on par with a university course covering human ethics and engineering. This is the tiny rock particle I mentioned at the beginning. And getting it moved will be one of many causes of positive and lasting change.

Just like telling a three year old “No!” for the first time, resistance will be swift and firm. Most developers burst out in a tantrum of foot stomping and howling. They don’t have the time much less the training to write tests. It’s not their job. Remain firm and show the benefits of moving quality control upstream. Toddlers know, deep in their hearts, the difference between right and wrong. Once you convince them they have the time, developers will too.

Next up on the list – telling system administrators about the importance of version control!

Other posts:

• A Luxury Problem: How Emerging Iterations Eat Team Commitment For Breakfast

Bill Abbott

Without monitoring, server changes can’t be analyzed to see you’ve really made things better (or even worse). And without testing, every commit you make is a risk to the running site.

Monitoring made easy

Pingdom is perhaps the simplest monitoring tool that literally anyone with a browser can setup. Even if you don’t want to (or can’t) spend a penny, they will track one URL on your site for free. Be smart, and point this URL to a critical, complex page on your site to verify as many running pieces as possible. Once entered, Pingdom starts collecting data on the page’s general availability and even response time (world-wide).

With the single free URL check from Pingdom, you literally have zero excuses for flying blind. As outages crop up, get the URLs that demonstrate these failures added to Pingdom. Stop being the last guy to find out that the web service is down and start being the one reporting it’s outage to team.

Getting your SNMP configured correctly is the next step and will allow you to do real low-level monitoring of disks, cpu, network, etc. If you don’t have the time (or know-how) to setup a front-end to report on all these data points, think about having an external service provider do it for you. Logicmonitor and Cloudkick are both excellent and reliable monitoring services.

Testing is not so easy

Testing is never easy. If it was, everybody would do it! While preparing a complete test harness for unit testing might take a month or two, don’t forget about some simple acceptance tests.

Here we have two options:

• Selenium
• Webrat

Selenium is probably the easier of the two to get up and running quickly (and without a lot of technical knowledge). The Firefox plugin makes recording simple workflows a breeze. If multiple browser support is also something you need, take a look at Saucelabs. There was some talk early this year about them allowing unlimited, free test minutes using Linux as the OS.

Webrat is a ruby gem that let’s you get your hands a bit more dirty (and do a bit of coding). And, as it doesn’t have to parse & render the response of the URL call, it’s much faster than an equivalent test under Selenium. What you gain in testing speed, however, you lose in javascript execution. If you have a critical feature that can only be accessed via javascript, either refactor, or test it with Selenium.

Write a simple login/logout test. If your site has a regularly used forum, write a test that creates/deletes a new topic or post. Such simple tests quickly become the foundation of your future build server!

By implementing these two steps, monitoring and testing, you have started down the path of gaining control over your environment. What other simple steps have you taken to avoid unwanted text messages in the middle of the night?

Other posts:

• Selenium Testing in the Cloud with Sauce Labs
• Approaching Legacy Environment Management with DevOps
• Devops in a Regulated Mainframe Environment

Kevin Parker

This is an interview with Kevin Parker (@kevinparkerusa) about DevOps

How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.

Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.

There is a very good reason why developers should care about release management: delivery of software that works is how the business judges that application development has been successful. If that release goes poorly, then the users will complain and the perception of IT will be affected.

Release management is key going forward. Automating this process should save you time as well as ensuring that all the good work that your application development function does is recognised.

How do you see web applications changing, and development for these environments changing as well?
More and more applications are shifting over to being web-based services, simply because this makes them available wherever users happen to be. For application delivery, this does make them more complicated, as the number of moving parts that are involved in getting data across to a user goes up. Web-based applications have numerous layers of technology that are highly interdependent and this leads to complex configuration management issues.

For developers, getting their applications updated when they cross over many different architectures, technologies, methodologies and geographies means that they have to be conscious of how all these interactions work. This means that testing, auditing and tracking changes is becoming more important, because if a service goes down, it can be more difficult to find where that problem came from during the development process.

Web applications need to be developed using agile methods and we must invest in looking at continuous improvement throughout the application delivery function. Because services have to be available online all the time, downtime becomes a more difficult issue to manage. At the same time, releases are coming through more frequently. This will pull application delivery and release management in two directions and needs to be managed in conversation with the business.

What does the future hold for DevOps?
Web services are hosted within businesses on many different servers – physical or virtualised – or can be put into the cloud. So there will be potentially more platforms to think about within the organisation – everything from Windows and Linux servers, through to mainframes and cloud-based services as well as handheld and embedded software on other devices. For operations, changes in these environments represent opportunities for things to go wrong, and managing these risk events is a big issue for them.

To reduce the impact of this, automating release management can help. Getting software updates deployed across these new platforms, irrespective of what that platform happens to be, is the main aim for both developers and operations. Instead of having this completed manually, automating the job stops errors creeping in.

The gap between developers and operations – DevOps – represents an opportunity for things to go wrong if the processes that should be followed are not clear. Getting the right workflow in place is therefore an essential part of planning application development going forward. Bringing developers and operations staff together to discuss the whole process is a good first step to solving the problems that can exist.

How will this affect the operations side as well?
I think the biggest issue will be one of collaboration – rather than being adversaries on either side of the gap, dev and ops should be seen as part of the whole route that application development and delivery has to take. Having this wider overview of the processes that should be in place can help both sides to see that they are being more productive.

This collaboration should come as part of the wider business process that exists around application delivery. For the business owners that are involved in requesting new applications or updates to existing software assets, being able to see where their requests are in the process is very useful to them. Converting what is going on in the world of software delivery into tangible business benefit is where I see the world of DevOps going in future.

For developers looking at managing applications across their life-cycle, DevOps represents an opportunity to get more of an insight into what the business really wants from them. As timescales are coming down for software projects to be delivered, this will be essential.

The other area that will change around this is how developers and operations integrate into IT service management. ITSM involves how the organisation runs its processes and manages delivery of IT services out to users. For most companies, their view of ITSM begins and ends at the service desk, but it actually covers much more than that. In the future, there will be greater collaboration around the provisioning of resources to support a service across operations and the business unit, particularly as these applications become hosted on virtual servers or in the cloud. For developers, knowing that this level of flexibility and management is needed will have an impact both on how they put their applications together, and how they include that ability to scale to meet requirements.

Other posts:

• The 5 Goals Of Agile And DevOps
• DevOps Entrenched – Tide Begins to Turn
• Devops in a Regulated Mainframe Environment

It’s been a while since I talked about how we develop and deploy software at my current job. It’s come a long way from the “Good Ole Days”, when cowboy coders manually FTP’d their changes to the master server and rsync came along 5 minutes later to replicate the changes to the slaves *shudder*. Keep reading below for the details.

github repository

We migrated to github from subversion about a year ago. Even though we don’t use that branches so often, I’ve found the speed & stability of git greatly improved and the amount of frantic recoveries due to user error (i.e. copying directories but forgetting to delete the damned .svn folder) dropped to zero.

As we’re using an Organization, we have a development team with access to the website code repository, and a sysadmin team with access to the puppet server configuration repo. What – no DevOps? As I mentioned last month, we’re not quite at the “Continuous Deployment” phase. Plus, I don’t think DevOps means giving sudo access to developers!

Hudson build server

Hudson is the core of our build environment. Every 5 minutes, it checks out new changes from github, runs a rake db:migrate and starts testing. First, ~250 phpunit tests comprising 30% of the codebase runs for 30 seconds. Concurrently, webrat runs ~70 tests with over 650 assertions for 2 minutes. These mostly ensure SEO relevant tags & text appear where expected.

A successful phpunit build triggers four selenium tests (hosted by SauceLabs) – primarily form-based, user-content generation tests, these are our most basic “smoke tests” on pages that use javascript (something webrat can’t do) and take about a minute each. We even do a Facebook Connect login & registration test using selenium.

A successful webrat build deploys the new codebase to staging, including synchronization of new static files to our test Amazon S3 bucket and purging of changed static files from our test Amazon Cloudfront instance.

Once a day, we have a “code quality” build. PHP PMD and Checkstyle tools do a sanity check on everything from class complexity to code syntax keeping a nice overall trend graph that helps us quickly identify bad commits. Admittedly, we use the information from this build as a “rainy day” refactoring backlog.

PivotalTracker integration

PivotalTracker (PT) is my favorite tool for Scrum based project management. What, at first, seems too simple for professional use, quickly becomes an organizational focus point for sprint navigation. Since I first introduced Scrum, we’ve stuck with weekly sprint iterations. The main reason being better able to focus on the tasks at hand – it’s easy to say you’re busy until next week. 95% of folks can live with this and, it also gives them motivation to show up for the sprint meeting!

Product management manages and prioritizes the Backlog with other stakeholders in the company during the week. In our weekly sprint, developers commit to delivering X amount of stories/tasks/bugs relying primarily on PT’s built-in Velocity calculation (an average of the last 3 sprints).

As stories are committed into github, developers mark them Finished. This cues the corresponding product manager to have a look on the staging environment (where caching, etc. is enabled to make it one step closer to production) for the final sign-off for release.

Capistrano release

We typically do 3-5 releases a week – even more for smaller, pixel-pushing type changes. When we’re ready to push live, we grab the last, accepted git commit revision id from Hudson (double checking everything’s green) and do a cap release c=|git_id| h=prod from our desktop.

Capistrano then logs into all the servers and reports the currently running revisions (in case of an emergency rollback), runs rake db:migrate for any database schema enhancements, pulls down the code from the given revision id, and does the same sync/purge of static files on Amazon.

It then sends out an email to the dev and admin groups noting the released revision and relevant environment(s). And, finally, it even goes into PT (making use of the API) moving all “Delivered” stories to the “Accept/Reject” phase and creating a release “Milestone” again with that git revision id as title.

As an added bonus, it even pushes all these stories up in the Current iteration just below the last “Accepted” story. Now, product management has a “speak now or forever hold your peace” chance to review the story live.

Testing and automating builds and releases is the quickest way to ship quality software. Like Snoop says, you gotta “drop it like it’s hot” – don’t let inventory code clutter your warehouse!

Other posts:

• Optimizing Offshore Software Development with Agile
• How “Good to Great” applies to agile software development
• Waterfall, SCRUM and Lean Software Development simulation as teaching platform

This is a guest post from John Willis (@botchagalupe)

What if DevOps created more defects, tickets, requests, and more overall work? Would that be a good thing or bad. Let’s take a look.

Information Technology Asymmetry

Let’s face it, IT has historically had an asymmetric relationship between it’s suppliers and consumers. In fact one of the core tenants of the “DevOps” problem statement is the relationship between developers and operations. DevOps is only about three years old but the concepts have been around a lot longer. This is nothing new, historically developers want rapid change and operations wants stability and slow change.

I once spent six months in a cubical adjacent to the change manager for one of the largest US based insurance companies. I wish I had a copy of my tweets about the hijinks she had to deal with from people trying to game their change management system. You enterprise guys know what I am talking about. Think of all the wasted time in IT that goes into trying to game the system due to lack of information and access to resources.

Another true story, I once spent a year at the Federal Reserve doing Tivoli consulting. On my first project I needed to get an Oracle instance for a Tivoli database. I created a change request. A year later I left the Fed with two things 1) a new Oracle instance I didn’t need anymore and 2) My wife.

Latent Demand

A situation where demand cannot be met: a business environment in which demand for a particular product cannot be met by existing suppliers or is temporarily suppressed.

Unfulfilled latent demand is root of all evil in IT. In my Oracle instance example I never again asked IT for resources (“Why Fight City Hall”). I was a consultant and I had to get things done on time. I had to steal database space from an already existing Oracle instance and it never fulfilled the true requirements of the project. I wasn’t the only one on the project that behaved this way. In the end this particular project ultimately failed at the Federal Reserve. There were other reasons for the failure… but what if we would have had a new Oracle Instance? or received that SAN based file system? or … the list goes on. Maybe Tivoli would have run better. Maybe customers of Tivoli would have seen it’s true potential. Maybe if…

Another great IT story is a customer of mine that is a large New England based bank. The last time I checked they were still waiting (18 months) for an approved new server. Of course they created their own “servers” during that 18 month period – it just didn’t happen to be that one they originally purchased for $30K. In fact, this is a common meme in the early cloud success stories – “I can go to purchasing and have them beat me up for 3 months or I pull out my credit card and just get it done.” However, this is still the exception rather than the rule. Most consumers of IT wind up waving the white flag and just don’t ask.

Supplier Induced Demand

The idea of supplier induced demand encourages consumers to demand a greater quantity of goods or service. What if IT could create an environment where consumers of IT were informed and felt empowered? What if IT gave them the freedom to get things done? What if freedom and a getting-things-done attitude became habit forming? Imagine if change requests were auto approved due to repeatable automation. What if, in the 18 month server example mentioned above, automated provisioning and configuration management were used to build that system in minutes? Imagine if the 10 or 15 people involved in the process of verifying that server had stored their process in a configuration database. Then automation could be used to deliver the best of both worlds. The consumer gets the server faster and the supplier has a secure and repeatable process. The business might create a lot more servers, a lot more services, and a lot more happy consumers.

One of the core principles of “DevOps” is about changing cultural habits to induce productivity. In DevOps we talk about breaking down the “Wall of Confusion” between developers and operations in order to become more agile as a whole. Most DevOps discussions focus on models of automation around provisioning, configuration management, continuous integration, monitoring and continuous delivery to enable that business agility.

What if Devops?

So let’s get back to my original question. What if DevOps created more demand, would that make things better? Let’s take one last detour before we answer that question. A few years ago Eli Lilly did a Webex on how they used Amazon’s cloud. One of my best take aways from that Webex was how they described the cultural habits that were changed by using Amazon’s cloud. One of the quotes in the Webex was – “Amazon has redefined the concept of time here at Lilly”. What the presenter meant was that it was great that they significantly decreased provisioning time; however, what was even more important was they had significantly changed a cultural behavior pattern. Prior to the “cloud” their researchers would have to either fudge or ignore short computations that were needed. Why? Because if they had to wait 8 weeks to get the server(s) or, even worse, ask purchasing for 100 physical servers for 2 hours, they would opt for the fudge method. In their cloud world the “new” definition of time was that they could ask for 100 servers for two hours to calculate the number they needed for a much larger computation. The end result was that Eli Lilly asked for and received a lot more servers than they did before the cloud. The question I like to ask IT organizations is – “Who are your most important consumers and have you identified their latent demand?”.

So back to the original question, “What if Devops created more defects, tickets, requests and more overall work?”. What if the support group actually fixed bugs faster? Consumers might actually start reporting more bugs. The product might improve and demand might increase. The end result could be that you make more money. What if you have created a self service environment for service requests. More service would be created and hopefully the consumption of those resources will create increasingly positive business results. Therefore, my answer to this question is yes, Devops will create more work. However, if the correct automation is applied the “more” work will actually cost you less, create more demand, and make your company more $money$.

About the author

John currently works at DTO Solutions, Inc. located in San Mateo, CA. With over 30 years of experience in ESM/IT Management, he is the author of numerous Tivoli books.

Other posts:

• Behavior Driven Ops, Kanban vs. Scrum and a new upcoming Monitoring and Trending Tool
• DevOps – What’s Up?