Add Chef to your Organization’s DevOps Kitchen

Companies looking at DevOps with the hopes of streamlining their software development process sometimes struggle with the initial implementation. Leveraging the right set of DevOps tools is an important factor in achieving success as much as any organizational or policy-based changes. One such tool – known as Chef – is especially helpful for shops taking advantage of the Cloud as part of their overall application engineering strategy.

What follows is a closer look at the features and functionality of Chef to see if it allows your team to manage server infrastructure quicker than ever before.

Open Source Server Configuration Management for the Cloud… and more

Chef’s main functionality centers on the management of Cloud-based infrastructure. It offers value to any company whether they manage ten servers or ten thousand – no matter the platform. It lets your development staff focus on ensuring their software runs properly, instead of having to deal with the drudgery of server administration tasks. While it truly shines in the Cloud, Chef also works with on-premise servers as well as a hybrid infrastructure.

A Code-based Approach to Server Management

What makes Chef unique among similar infrastructure management tools is its emphasis on using code to define and automate a collection of servers. This lets you handle automated server management in a similar fashion as your applications, with development, QA, and production environments ensuring a high level of quality. Additionally, letting your developers manage servers using code fits nicely with the overall philosophy of DevOps, where formerly segregated duties are handled in a more communal fashion.

A development kit, known as the Chef DK, includes everything required to develop and test infrastructure automation code. Test Kitchen handles the running of these tests, using InSpec as the TDD programming language. Not surprisingly, the included code analysis tool is known as the “Food Critic.”

Continuing with this kitchen metaphor, the collection of code used to automate and define a server infrastructure is known as a cookbook, and – of course – they are made up of recipes. This nomenclature definitely helps developers new to Chef better understand the functionality of each part of the system. Behind this somewhat humorous style lies a very powerful tool.

The Chef Server is the central repository for every cookbook in the system. This design allows the Server to manage any number of physical or virtual machines in your infrastructure. The Chef Client runs on each of these nodes; staying in constant communication with the Server.

An Essential Tool for DevOps

As noted earlier, Chef offers any DevOps organization the means to manage their technical infrastructure easier than before. Its code-based scheme for server management lets you leverage your development talent in a new fashion. The kitchen-based metaphor used in Chef also makes it easy to understand by both your technical and non-technical team members.

Chef, and similar tools, like Ansible which we previously covered, play an important role in any company deriving value from its investment in DevOps. Ultimately, this is a methodology requiring more than just a change in organizational structure for success. Download Chef to see if it makes sense in your shop.

Thanks for reading the Betica Blog. Keep coming back for additional insights from the software development world.

Software Architects need these Four Essential Skills

Of course, strong technical ability is a requirement for anyone employed as a software architect. This role is almost always filled with someone who forged their skills working at least a few years as an application engineer. What separates the best architects from those merely holding the job title are the other intangibles necessary to thrive in today’s business world.

O’Reilly Media recently looked at four essential abilities a software architect needs to truly be successful in this era of Agile and DevOps. Let’s take a closer look at these skills to see if adding them to your toolbox makes you better at the practice of software development. Good luck!

Technical and Business Leadership

A good software architect knows how to lead the developers on his team, while also working closely with business stakeholders and project managers to ensure the project requirements are clearly defined with sufficient progress being achieved. Mark Richards, an experienced software architect and author, commented on the importance of this trait.

“It’s being a technical as well as business domain go-to person, it’s really to help clear roadblocks to the team so they can actually move forward. Being a leader as an architect means providing technical help and guidance, it means to help the team make decisions and form those decisions and validate them, and also to provide motivation to the team and support whether it be technical or non-technical support,” said Richards.

The Ability to Negotiate

Software architects also need to be able to negotiate at times to ensure a technology project proceeds in a smooth fashion. This skill comes into play when first determining the technology stack and basic architecture for an application. Sometimes, stakeholders may want a feature beyond the scope of the project or its budget. Similar negotiations happen with project managers and even the development staff, ensuring buy-in before the actual work commences.

Strong Decision-making is a Must

While the product owner or project manager typically rank higher in the hierarchy of most technology projects, a software architect still needs to possess strong decision-making skills. This especially comes into play regarding the technology stack used on a project, i.e. programming language, database, virtualization platform, etc. A strong-minded and confident approach definitely helps to formulate a robust architecture for a software application.

Collaboration is Vital in Today’s Technology World

It stands to reason any software architect working at a company with a DevOps organizational structure knows how to collaborate with their coworkers. Many enterprises also use architectural teams to define system architectures as a group. In this latter case, being able to share ideas and concepts with other like-minded professionals – in an ego-free fashion – helps ensure the best possible applications are built for the organization. Richards feels a mediator role helps when architectures are defined using a team instead of an individual architect.

In any case, it is obvious the best software architects possess a variety of skills that go beyond writing great code. Consider developing these abilities in your own work to take your software development career to a higher level.

Thanks for reading the Betica Blog; check back soon for additional news and insights from the constantly changing software development world.

Business continue to strive for Continuous Integration

One of the major reasons companies eschew older software development methodologies for Agile is to make the process faster, more nimble, and ultimately better able to meet the constantly shifting needs of the business. The “holy grail” of this effort is usually continuous deployment or continuous integration, where software updates typically happen on an hourly basis. In a competitive business world, this kind of transformation is sometimes necessary for survival.

Embracing state of the art innovations like containers and automation also remain part of the process, but let’s take a closer look at the current struggle for enterprises to achieve continuous integration. Maybe these insights help your own company undergo a similar evolution in software engineering.

Continuous Integration not widely Implemented… yet

A recent study by Dimension Data, and reported on in Information Week, looked at the adoption of Agile and continuous integration at the modern business. Over 700 industry professionals responded to the study; working at companies of all sizes from the enterprise to the SMB. The survey noted the wide popularity of Agile throughout the technology world, and while continuous integration is a worthy goal, a relatively smaller number of organizations have yet to achieve it.

About one-third of the respondents reported a full engagement with Agile among all their software development teams, while 94 percent noted at least part of their organization’s software engineering process used Agile. The other six percent either didn’t use Agile at all or were experimenting with the methodology on a pilot project.

For the purposes of the study, continuous integration is considered to be the ability to deploy software updates on an hourly basis. 28 percent of the surveyed organizations consider that level of CI to be their ultimate goal with Agile, while only half of those firms achieve it today. Dimension Data noted that 18 percent of last year’s survey respondents had CI as a goal, showing a notable increase on the current survey.

Faster Software Updates and Bug Fixes

Even if companies don’t reach that final goal of hourly software updates, they are still reaping the benefits of Agile, according to the survey. 35 percent of the respondents integrate updates on a daily basis, while 17 percent are able to do so every week. Another 20 percent update their systems on a less than weekly basis, but still faster than with older methodologies, like the Waterfall.

Naturally, bug fixes also happen more quickly when using Agile – likely with other software development innovations contributing to the higher efficiency. These speed improvements were relatively minor – a few percentage points – probably due to software enhancements being more important than anything but critical fixes. Around 20 percent of the respondents use test-driven development and are seeing fewer defects as a result.

87 percent of those surveyed embrace some form of automated testing, with either Selenium and/or Appium being used by 70 percent. The use of DevOps is also emerging with 88 percent of the respondents either considering it or already leveraging some of its practices.

The bottom line remains simple: If your organization is interested in a faster development process, obviously Agile needs to be on your radar if it isn’t already. You may never reach continuous integration, but benefits are able to be achieved throughout your journey.

Stay tuned to the Betica Blog for additional dispatches from the world of software development.