devopsy.kinsta.cloud

Category: Features

DevOps and legacy system lessons from dwarf planet Pluto

If you’re a bit of a space geek like me, then maybe you’re one of the 243 thousand plus followers of #NASANewHorizons; diligently monitoring deep space twitter sphere for the latest news and pictures from dwarf planet Pluto.

The success of the New Horizons project is incredible – especially when you consider it’s all been delivered by legacy technology. Technology that lifted off back in 2006 – when Pluto was a real planet and before we had the iPhone, mobile apps, social media, Big Data, the Internet of Things, oh and DevOps.

So why did this nine year old piano-sized hunk of tech deliver so impressively, and what lessons are there for those of us in IT managing our own legacy systems and applications? Actually there’s a lot we can learn from the outer reaches of our solar system.

Even in Deep Space constraints can be managed

The New Horizons space probe is an extreme example of a constrained physical system. Three billion miles from home, command sequences take 4.5 hours to reach the probe and the consequences of screwing as it barrels along at a lazy 30K mph are, well, pretty severe. Of course NASA scientists have a fallback – they use a simulator with engineering and telemetry models to test the commands that perform all the vital spacecraft activities.

In business computing we don’t have the luxury of having spare hardware of tap – especially for large legacy systems. Too often access to systems and data needed for development testing is constrained due to schedules, contention, security restrictions or service provider usage fees. To address this many organizations attempt costly provisioning of lab infrastructure, but these often don’t fully reflect production condition.

As with New Horizons, constraints within IT can be eliminated with technologies that model and simulate the behavior of dependent systems. This not only lowers infrastructure costs, but also helps teams move testing activities earlier in the lifecycle, where in parallel with development help detect software defects well before they impact production systems.

Change and release co-ordination is critical

Just days out from its rendezvous with Pluto, New Horizons suffered a minor glitch and lost contact with the earth. For a $700 million probe at the edge of the solar system, that caused a few jitters. Then after a day of analysis (and maybe some head scratching), mission control tracked the problem to a timing flaw in the spacecraft command sequence. Basically, the main computer went into safe mode after being asked to do two intensive tasks at once.

In enterprise tech our own legacy applications play an essential role in supporting key business processes. As such, and like New Horizons, changes must be carefully coordinated. What’s different, however, is the scale of the challenge. Multi-tier release deployments by nature are inherently complex with many dependencies. Automation therefore is critical, as are reusable and repeatable deployment processes to streamline application releases involving legacy systems.

Data can be exposed and utilized in different ways

It’s interesting to see how NASA have exploited social media for the New Horizons mission. Thanks to blogging, podcasts and Facebook all the news and fantastic images are now easily accessible. From the web-site too, the twitter API has been exploited to provide a constant channel of updates and facts about the legacy technology – did you know for example that the original PlayStation CPU (MIPS R3000) is used in the probe? – I guess if it worked solidly for a 100 million game units it can fire some thrusters 3.5 million miles out in space.

Businesses operating in an economy governed by software applications can take a lesson from the New Horizons mission. Application Programming Interfaces (APIs) are now central to the exchange of value between companies, so it makes complete sense to use them against legacy systems and line of business applications. By securely unlocking the application data (and business processes) through API’s and by seamlessly managing message mediation and translation, organizations can have these older systems quickly participate in more modern processing and customer-centric computing.

Every system is a legacy system

Just as we rush to embrace every shiny new tech object, we can be equally hasty berating the value of existing systems and applications. To this end, legacy becomes a term of derision; associated with everything bad about enterprise computing. The more pragmatic among us know this isn’t so. After all these systems support a plethora of back-end business processes and continue to be the transactional work-horses upon which many businesses depends.

There’s a lot we can learn from the New Horizons mission. Even now scientists are saying that the spacecraft has decade’s worth of exploration left in it. So with some quick course adjustments it’s off to explore the next icy world.

Not bad for old space tech – perhaps in business computing we should be thinking the same way – extracting value before prematurely consigning our own legacies to application scrap-heap.

September 24, 2015
DevOpsSec – Creating the Full Triangle

Introduction

As a discipline, DevOps emphasizes uniting development and IT operations teams through modernized culture, integrated tooling and processes in order to increase the frequency, quality and business alignment of software roll-outs. But while developers and IT Ops teams need to be in lockstep, security cannot be an afterthought. Rather, DevOps teams need to adapt to include security as an integral part of the agile triangle.

The challenge facing DevOps teams today however is that incorporating security into their day-to-day work is not always easy or intuitive. Security often runs one step behind or out of sync with lean DevOps teams. In addition, the besieged security professional or team often faces a never-ending barrage of breaches, designed by a large, amorphous and highly motivated hacker ecosystem and resulting in a continually escalating threat environment. In an effort to save time, agile developers may leverage existing code in rapid iterations and quickly deploy them to production through continuous delivery pipelines, without considering existing architectural defects or knowing its defect profile and potential for security vulnerabilities. This can expose organizations to huge risks if left unassessed and mitigated.

Fortunately, “security at the speed of agile” is entirely possible, allowing organizations to bring new software products and services to the market, while staying in control. Here are some best practices for better aligning security with DevOps objectives, evolving beyond just DevOps to DevOpsSec:

Shifting security “left” in the DevOps chain

Like functional quality testing (making sure an application works as it’s supposed to), security testing needs to happen in the earliest possible stages of the development process. Traditionally, the application lifecycle has followed a sequential model – ideation, development, testing and finally, production. Functional testing used to occur only during the testing phase. But now, developers are taking on more responsibility, which helps prevent defective code from getting “baked in” further down the application lifecycle, where it becomes much more time-consuming and costly to undo. However, security is also an extremely important part of the quality equation, and if a security defect isn’t detected early on, a very unpleasant surprise is likely in store as the application gets closer to production. Building in and continuously integrating static code analysis and dynamic security testing into the Agile application lifecycle is a key success factor to delivering a high quality, secure application experience in production.

Automating security testing, for both developers and testers

In agile environments, DevOps teams are under constant time pressures. As noted above, developers are expected to develop more and more code, all while assuming greater responsibility for functional quality. Testers, too, are under increased pressure as more frequent application roll-outs mean more testing, in less time. For these reasons, if security testing is going to take place earlier on in the application lifecycle, basic security tests need to be automated. Since security threats are constantly evolving, this kind of automation will not completely rule out all security flaws in production. But it will allow developers and testers to spend more time on their core functions – namely development and functional testing – while lowering the attack surface, once an application does reach production.

Leveraging Big Data analytics

Data generated from DevOps processes and operations, particularly related to automated security tests, often hold a wealth of insights which can be used to step up security validation efforts throughout the application development lifecycle. For example, what code types show the most vulnerabilities and therefore may need more rigorous testing? Which groups of developers are discovering the most security holes in automated tests – such that their development processes may need to be refined — and which groups may not be testing enough? How long are basic security tests taking on average, and how does this need to be factored into roll-out timelines? This type of data can help DevOps teams prioritize and optimize their security testing, and better reconcile security testing requirements with velocity and resources to hit anticipated delivery dates. Also, while using Big Data analytics in production will always be useful (particularly when it comes to detecting new security threats, and determining new automated testing needs), applying Big Data analytics earlier on, to DevOps pre-production data, can prevent more security flaws from making it into production in the first place.

Fostering a shared vision and objectives

To date, real progress has been made uniting developers and IT operations teams together in DevOps organizations. Traditional roles and responsibilities within DevOps teams continue to evolve and coalesce, and that’s a good thing. Developers are contributing to testing and taking more responsibility for overall quality. IT ops teams are thinking like developers, analyzing and feeding production data back to developers and testers so they can fine-tune and modify their offerings. Data flows left-to-right, and right-to-left are becoming more automatic and continuous.

But increasingly, security professionals need to be included in this mix. Developers need to think with security considerations in mind – for instance, will a new feature they want to add to an application bring increased security risk, and if so, how can this risk be minimized? Conversely, security professionals need to think like IT ops teams; for example, making sure a new mobile app doesn’t potentially create a hole for hackers to penetrate back-end systems, and if a hack were to happen, how to contain it and minimize the impact. Only by capturing the right data, communicating and committing to working together can everyone in the DevOpsSec chain make the best, most well-rounded decisions that factor in all concerns, with business success being the top priority.

Conclusion

Often, DevOps teams may view security teams as potential logjams preventing them from doing what they want to do – deliver working software quickly to delight users and create competitive edge. But if security in the software supply chain is not addressed, the results may do the exact opposite, frustrating users, freezing business processes or worse, causing massive financial liability and loss of brand goodwill.

Security is a key ingredient of application quality. By addressing security earlier in the development process; increasing security testing automation; leveraging Big Data analytics and incorporating security in the DevOps mission, organizations can achieve true DevOpsSec and deliver applications that are high-quality, through and through.

About the Author/ Kelly Emo

Kelly Emo, Director, Lifecycle and Quality Product Marketing, HP, Kelly has been involved in all things IT for few decades, including engineering, product management, and product marketing across application development, SOA and middleware, enterprise architecture, IT operations, quality and testing. She now focuses on application lifecycle management, quality, agile development and DevOps. She has worked in other organizations at HP, BEA Software, and Jamcracker Inc .Kelly has a BS in Computer Science from Cal Poly, San Luis Obispo and an MBA from Santa Clara University.

September 23, 2015
4 big challenges of microservices

The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

Al Hilwa, research director, Application Development Software at IDC described microservices this way:

“Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

1. Insufficient guidance

When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

2. Getting it wrong

There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

3. No going back

You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

4. Deliver value

Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

September 21, 2015
The Scalable Path to DevOps Career Training & Development – A Premium Talent Marketplace

“Our company is a premium talent marketplace with on-demand leadership and clients mostly in the Bay Area, Silicon Valley, New York, and other metropolitan areas,” says Tomas Gutierrez, Partner, Scalable Path, a geographically-distributed network of more than a thousand software architects and developers. Scalable Path serves clients such as tech startups and product companies by helping them build software teams and fill technological gaps. Given that Scalable Path assists with software design, its clients most certainly have needs in DevOps approaches. Scalable Path’s Gutierrez informs devopsy.kinsta.cloud about DevOps career training and development priorities and building blocks.

Foundational Knowledge

At Scalable Path, a good working knowledge of the seven layers of the Open Systems Interconnect model is important for software engineers who want to work with DevOps approaches. “In order to have a full mental picture of what is happening where, software engineers must have a conversational knowledge across all these layers,” says Gutierrez.

With any application of software, you will host it on hardware, you will have an OS, and hosts will talk to each other across a network. “The DevOps engineer must know the seven layers involved in order to consider goals for infrastructure as code and to help with software releases, deployment of infrastructure, networking, and configurations,” explains Gutierrez.

Applicable Traits

On the job, a good DevOps engineer must be a good problem solver, be able to think outside the box, and have empathy for the needs of the software product and the organization, says Gutierrez. Attention to detail and a security focus are also worth accounting for.

“Even though it’s good to have formal training, college degrees, and certifications, the right personality, that of an autodidact (one who is self-taught) is key for good DevOps talent,” says Gutierrez. These engineers will examine a technical challenge globally and in its component parts and seek and assemble the tools and processes that will provide a complete solution.

Further, someone who is empathetic to the needs of the software and the enterprise deploying it will realize when they need to use a simple, cost-effective software deployment without all the extras.

The ability to direct a focused attention to the details of software engineering is another important trait for a DevOps engineer. Otherwise, programming errors occur that can create issues down the road. “If you don’t architect something correctly, you may end up with part of your architecture failing because you made some mistake in programming,” says Gutierrez. These things can propagate and scale up into bigger issues as the architecture grows.

It’s also important for the DevOps engineer to be strong in security such that their programming does not expose critical data. It’s about how the programmer constructs the data layer, how they work with the transport layer, and what the end to end route is for the data, says Gutierrez.

Certifications

Despite the emphasis on traits and approaches to challenges on the job, there are certifications of value to the DevOps engineer. “The Cisco certifications, for example, especially the ones for networking will be helpful since a lot of what you will be doing in DevOps is about data in flight,” says Gutierrez. DevOps engineers need to be mindful of how traffic is moving over the Internet and to and through the data center, explains Gutierrez. Network configuration and network security expertise especially such as is validated through the higher Cisco certifications will be important for the DevOps engineer, Gutierrez adds.

Application security certifications are also useful as are vendor certifications and courses from Chef, Puppet, and Docker as well as platform vendor training from AWS, Digital Ocean, and the like.

Individualized Learning

User documentation and “try me” opportunities for different tools such as containers and configuration management, automation, and deployment tools are helpful for self-starters and people who run into problems or have questions along the way. “People engaging in these kinds of training can simply create local laboratories for these tools on a local machine to simulate the larger application or architecture they are trying to learn,” says Gutierrez.

In order to learn how to navigate the in-depth areas between the system and application architectures, the DevOps student should consider the books in and around these subjects. Just a few examples include, “DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)”, “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, and “Salt Essentials”.

September 18, 2015
The Scalable Path to DevOps Career Training & Development

“Our company is a premium talent marketplace with on-demand leadership and clients mostly in the Bay Area, Silicon Valley, New York, and other metropolitan areas,” says Tomas Gutierrez, Partner, Scalable Path, a geographically-distributed network of more than a thousand software architects and developers. Scalable Path serves clients such as tech startups and product companies by helping them build software teams and fill technological gaps. Given that Scalable Path assists with software design, its clients most certainly have needs in DevOps approaches. Scalable Path’s Gutierrez informs devopsy.kinsta.cloud about DevOps career training and development priorities and building blocks.

Foundational Knowledge

At Scalable Path, a good working knowledge of the seven layers of the Open Systems Interconnect model is important for software engineers who want to work with DevOps approaches. “In order to have a full mental picture of what is happening where, software engineers must have a conversational knowledge across all these layers,” says Gutierrez.

With any application of software, you will host it on hardware, you will have an OS, and hosts will talk to each other across a network. “The DevOps engineer must know the seven layers involved in order to consider goals for infrastructure as code and to help with software releases, deployment of infrastructure, networking, and configurations,” explains Gutierrez.

Applicable Traits

On the job, a good DevOps engineer must be a good problem solver, be able to think outside the box, and have empathy for the needs of the software product and the organization, says Gutierrez. Attention to detail and a security focus are also worth accounting for.

“Even though it’s good to have formal training, college degrees, and certifications, the right personality, that of an autodidact (one who is self-taught) is key for good DevOps talent,” says Gutierrez. These engineers will examine a technical challenge globally and in its component parts and seek and assemble the tools and processes that will provide a complete solution.

Further, someone who is empathetic to the needs of the software and the enterprise deploying it will realize when they need to use a simple, cost-effective software deployment without all the extras.

The ability to direct a focused attention to the details of software engineering is another important trait for a DevOps engineer. Otherwise, programming errors occur that can create issues down the road. “If you don’t architect something correctly, you may end up with part of your architecture failing because you made some mistake in programming,” says Gutierrez. These things can propagate and scale up into bigger issues as the architecture grows.

It’s also important for the DevOps engineer to be strong in security such that their programming does not expose critical data. It’s about how the programmer constructs the data layer, how they work with the transport layer, and what the end to end route is for the data, says Gutierrez.

Certifications

Despite the emphasis on traits and approaches to challenges on the job, there are certifications of value to the DevOps engineer. “The Cisco certifications, for example, especially the ones for networking will be helpful since a lot of what you will be doing in DevOps is about data in flight,” says Gutierrez. DevOps engineers need to be mindful of how traffic is moving over the Internet and to and through the data center, explains Gutierrez. Network configuration and network security expertise especially such as is validated through the higher Cisco certifications will be important for the DevOps engineer, Gutierrez adds.

Application security certifications are also useful as are vendor certifications and courses from Chef, Puppet, and Docker as well as platform vendor training from AWS, Digital Ocean, and the like.

Individualized Learning

User documentation and “try me” opportunities for different tools such as containers and configuration management, automation, and deployment tools are helpful for self-starters and people who run into problems or have questions along the way. “People engaging in these kinds of training can simply create local laboratories for these tools on a local machine to simulate the larger application or architecture they are trying to learn,” says Gutierrez.

In order to learn how to navigate the in-depth areas between the system and application architectures, the DevOps student should consider the books in and around these subjects. Just a few examples include, “DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)”, “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, and “Salt Essentials”.

September 18, 2015
‘Tis the season to up your speaking game

Well it’s football season in the US, that means Fall is here. It also means that we are coming up to conference season. No matter what segment of the IT market you live in, there are probably a slew of conferences both local and national/international vying for your attention and attendance. For the overwhelming majority of attendees, going to a conference means watching and listening to others speak on topics of interest. Maybe this is the year you should really up your game by speaking!

This was driven home for me last week when I was speaking with the IBM DevOps team. We were discussing how plans for IBM’s InterConnect 2016 conference were coming along. The call for speakers for this major event is open until September 25^th. The IBM team was very pleased that the DevOps stream is tracking among the leading topics for submissions for InterConnect 2016.

That is really quite a feat when you consider the scope and scale of the event. InterConnect 2016 is IBM’s Premier Cloud and Mobile event, February 21-25 in Las Vegas, and is expected to draw over 20,000 attendees, delivering 2,500 sessions, workshops and labs in 10 major topic areas – including DevOps – and infinite networking opportunities. But it also speaks to both the popularity of DevOps in general and IBM’s focus on it in particular. In fact, the DevOps stream covers key DevOps adoption paths: Plan, Develop, Test, Release and Deploy, and Operate. There is a track specifically focused on transforming application delivery with DevOps, and another track called DevOps for Enterprise Systems that will focus on topics related to continuous delivery for two-speed IT including z Systems and Power Systems. There are other streams such as App Platform, Hybrid Cloud, Mobile and Security where DevOps topics will appear. Each track is packed with quality client success stories, technical deep dives, labs, meet-the-expert panels, interactive workshops and more. What’s nice is the sessions are tagged for interest for management and techies and for skill-level. There is a ton of content.

To find out more join me and 14 great DevOps leaders on the crowd chat DevOps: Code, Culture & Community on September 22, 2015 @ 1pm eastern time (60 minutes). You can visit https://www.crowdchat.net/ibminterconnect2016 to add to your calendar or follow along on Twitter #ibminterconnect2016.

So what does this mean to you? It means that there are still some great slots available to share your DevOps skills, lessons and experience with the world. Having spoken at numerous events over the years, I can tell you that participating as a speaker in an event brings a completely new level of learning and understanding. It is also a great way to meet your peers, other speakers and attendees and expand your own network.

What should you talk about? That is probably the biggest obstacle for many people submitting to speak. Randy Newell, Director, DevOps Marketing at IBM, commented to me,”highly-rated sessions are typically DevOps journeys told by peers – shared candidly, complete with the successes and the challenges around technology and culture. Transparency and passion, told from the front lines, go a long way.” I feel that you should speak about what you find interesting. If you find it interesting, chances are others will find it interesting as well. Also, when you are speaking about something interesting to you, your passion for the topic will shine through and others will feed from and join in your passion.

In a large show like this, the good news is that with all of the session slots available they have the ability to afford people to explore specific aspects of a subject that might not be available at a smaller event.

If IBM’s InterConnect is not the event that you choose to share your thoughts and ideas with the world, that is OK too. Pick another event and submit to speak there.

Of course speaking at conferences like InterConnect is a great career move, raising your stature and visibility among your peers. But beyond your own personal benefit, it really benefits the whole community. The best way for us to learn is to share our experiences and stimulate the discussion.

I realize that some of you reading this may still be hesitant to take the plunge and submit to speak. If that is your final decision, of course that is OK, too. You can still be an active participant in sessions by asking questions, joining the conversation. Don’t be a passive conference attendee. You get out of these conferences what you put into them.

As for me, I have two or three different speaking topics that I am submitting this week. Some are panels where I will be with key DevOps thought leaders and influencers who are also my colleagues to discuss key trends defining the future of DevOps. Panels are a great way to get your feet wet with speaking at events, btw.

So what are you going to do? Share your lessons learned, explore new frontiers, advance the state-of-the-art. Call for papers for IBM InterConnect 2016 is ending on September 25^th. Don’t miss the opportunity to up your game by speaking at the biggest DevOps event of the year! Submit to speak at IBM InterConnect 2016 today. http://www.ibm.com/cloud-computing/us/en/interconnect/

September 17, 2015
DOES15 – A Focus on DevOps Execution

“I recently attended my second DevOpsDays, and even one year later I noticed that the audience had changed a lot” – says Travis Cunningham a Software Engineer at SmartFile during an interview about their development environment. What Travis is speaking to is the fact that DevOps has matured dramatically in a short amount of time. Around two years ago the community was a members only club. It consisted of the innovators, and smaller organizations who could adopt DevOps in one fell swoop. But now the benefits of DevOps are shared objectives for most organizations.

(more…)

September 16, 2015
The Third “S” To A Successful App: Street Smarts

We have discussed how scalability and simplicity are leading factors to an app’s success, but in addition to having a strong coding skill set, developers need street smarts, or knowledge of the state of the market and of themselves. Why? Because an app is unlikely to reach its full potential and achieve success without the developer knowing their strengths and what markets to build for. That is the third “S” to successful app.

Know Your Strengths

A key characteristic developers need to know is their strengths. People are always coming up with new ways of doing things, and it is easy to get caught up in the latest programming language or new database technology. While new tools can be helpful and support your development initiatives, it can also be time consuming to learn how to use them. When you have a great idea, stick with your strengths and build a product you know will work, without losing time.

Identifying strengths also applies to choosing which platform to develop for. The language or platform you are strongest at or have a specific preference for should be used for at least the first version because it will allow you to make iterations more quickly.

With strengths come weaknesses, and it is important to be able to identify those as well. For example, sometimes a developer is unable to go out into the field to gather user feedback. When this is the case, it may be wise to look into bringing in a market expert. This is an individual who is an industry expert in a certain marketplace; ideally for a market that you have an app idea for. By bringing in a market expert, you’re able to marry your coding skills to their market knowledge to gain deep industry knowledge of the marketplace while allowing the developer to focus on building something great.

Market Validation

Whether a specific market expert is brought in or not, a good app developer should realize the importance of user feedback immediately. More often than not, a developer will have an idea for an app and go into a code trance, where they start hacking and building code but does not take the time to develop a long-term plan for their vision. Building an app without market validation can be very risky, as developers want to get into the code but fail to take a step back to identify what they can use to validate the need for their app.

AppSumo, an app that offers bundles of software for discounts, started out with a very lean model where the developers would manually input website traffic data into a spreadsheet and then analyze the purchasing behavior of their target audience. AppSumo had no code written at all, but this manual data input allowed them to validate the need and demand for their product. Because of this initial research, when they started writing their code, the team knew the app would be valuable.

Ship Imperfect Products

Once you have market validation, you’re ready to build and eventually ship your product. It’s important to know where to cut corners in the beginning so you can ship product as soon as possible, and also knowing where you can’t to ensure you’re shipping a quality product. This is ultimately the hardest facet of management: knowing how much tech debt to accrue and when to pay it off.

In the case of a brand new app, it may be best to accrue tech debt and solve it at another time because shipping a perfect product that no one uses means you’ve essentially wasted precious time. Willingness to failure is critical to success. It is rare to release an app that has perfect product fit, that perfection comes from rounds of testing and versions. Therefore, a key component of developer street smarts is a willingness to ship imperfect product.

Final Thoughts

Gaining effective developer street smarts means interacting with other developers to learn their perspectives and gain their knowledge. Sharing stories, asking questions and challenging yourself are all a part of becoming a better developer. This means taking some time off-screen and going to meetups, listening to talks and elevating your skills by learning new things. You’re also growing your professional network which increases opportunities for your business and your personal brand. These opportunities begin through the online channels with research, but getting out in the world and making face-to-face connections is invaluable for becoming a better developer and creating the best apps.

September 11, 2015
Chef raises $40m and a full house
Big news today from Chef who announced a $40m Series E round of financing. This round and its size is indicative of the continued high demand of DevOps in general and for a leader in the space like Chef. The round was led by DFJ Growth. Existing investors Battery Ventures, Citi Ventures, DFJ (venture), Ignition Partners, and ScaleVP also participated. Other noteworthy new investors in this round are: Millennium Technology Value Partners & Hewlett Packard Ventures (as a strategic investment).

I had a chance to speak with Barry Crist, CEO, Chef. Of course Barry was very excited about the raise (what CEO wouldn’t be) but what really made an impression on me is that Crist was excited on several levels about this announcement:
1. While Chef didn’t need the capital right now, as Crist says, “the best time to raise money is when you don’t need it.”, The money came at a time when the global market for DevOps is exploding and Chef is exerting its leadership in taking DevOps to the mainstream. With more than half of the Fortune 50 using Chef, 80 percent of Chef’s exponentially growing revenue comes from enterprise businesses.
2. Chef has scored a rare double of both DFJ Growth and DFJ Venture investing in Chef. Having both arms of the well known investment house among Chef’s investors is both a testament to how much they value Chef and how well Chef has performed to date.
3. The strategic investment by HP Ventures represents one aspect of a deep and growing relationship between HP and Chef. HP is poised to be a strategic partner bringing Chef to its large world-wide channel. This investment speaks volume about HP’s commitment to this relationship.
4. A full house for Chef. With the HP investment, Chef now has deep strategic relationships with Microsoft, AWS, IBM and HP. This represents a “full house” of major technology partners and bodes well for Chef to continue its dominance as the leader in DevOps automation.
This was a series E round for Chef and I did not ask Crist what type of valuation this money was raised at. But one of the nice things about raising money when you don’t have to is that generally you can afford to be a little pickier and get better valuations when you raise money.

I had a chance to speak with Crist about his outlook on the VC and investment market. With many voices chiming in that we might be seeing a dip in investment and valuations in the tech market, Crist said he didn’t have a crystal ball. But all the more reason to raise this money now. If the market does turn those with cash in the bank and dry powder will be in the cat bird seat to leverage their capital for strategic purposes. We might very well see Chef as an acquirer of technologies to tuck in as they continue to grow.

In the meantime, a rising tide will lift all boats. This kind of investment and buzz in one of the DevOps market leaders should help other DevOps companies in their own capital raising activities. While few may achieve the heights that Chef is rising too, there is lots of room in the market for DevOps companies of all shapes and sizes.

Congratulations to Barry and the rest of the Chef team on this raise and looking forward to see what the future holds.
September 9, 2015
The Sea Change that is DevOps – DevOps is changing tools and infrastructure as we know it: Part 2

In the first part of this series, I explored the factors that have lead DevOps to where it is today. From a three to six month deployment period to regular weekly (or even daily) deployments, DevOps has certainly changed the IT landscape as we know it. Now, with the growing adoption of a DevOps mindset, the IT world is seeing a huge growth in software companies created specifically for DevOps professionals.

The explosion of monitoring tools and evolution of the software engineer role

With the added complexity of SaaS software and the rapid innovation of the platform, issues occur more frequently. With the adoption of unified cloud infrastructures more and more of these issues are application layer in nature. Service providers like Amazon are now consuming the need for foundational monitoring from tools such as Nagios at the IaaS (Infrastructure-as-a-Service) layer. Today, problems are popping up at a higher level in the stack and, monitored by tools such as NewRelic, that output is directly destined for software engineers. The ability to know if something is working correctly is now a comparative operation performed by the engineers who wrote the software.

The changing landscape of the NOC

If getting software built and into production was the nirvana that everyone had been marching toward, the NOC (Network Operations Center) was the manual switchboard of the past standing right in the way.

Traditionally, the NOC has been the catchall command center for people who monitor the systems that monitor the software. NOCs were designed to be the first line of defense against technical problems, customer problems, and general communication of issues to the wider company. Historically, NOCs have had an infrastructure bias as the software higher in the stack changed less often. But as the true infrastructure layer of SaaS companies began to move away from the company and into IaaS platforms, that need was receding. At the same time, as application deployments were increasing in frequency, often first responders that were not highly technical were adding drag in system resolution times.

Today, companies are looking for ways to direct problems straight to the “makers” that created that component of software in the first place. With the speed of SaaS businesses, the company can no longer afford for the first responder to be anyone other than the person or group that created the logic in the first place.

If the NOC of the past had two critical functions, solving technical problems fast and communicating with internal and external stakeholders, suddenly half of their charter was starting to fail dramatically. This led to the explosion of software like VictorOps and monitoring tools like New Relic and AppDynamics to help diagnose these problems quickly.

Operations is dead, long live DevOps

In all this time a lot of things have changed for operations people. While a technical operations manager in the past might hire system admins to do all the manual configurations, now they are looking for team members with coding skills. While understanding hardware was a requirement in the past, now suddenly virtual servers that you can rent from Amazon, Rackspace or any of 30 other IaaS providers can be created (spun up) in an instant with no knowledge of hardware at all. In the past a system admin had little to no knowledge of how the application software worked, but now that is their primary job description. In short, today you want to hire a software developer of a different skill set – one that codes the infrastructure and understands the application. While the NOC was once your first line of defense against system problems, now the team that wrote the software is the only defense necessary for technical matters.

For many, the end game has been realized

Now, for more progressive companies, the big gain has been realized. After literally a decade of innovation, for the first time it is easier to fix a production problem in-stage, rebuild and redeploy (all automatically) than it would be to fix the problem in production. Today the reality of being able to execute an Agile development sprint front to back is possible.

September 8, 2015