Category: Blogs

  • Putting People Before Software

    Putting People Before Software

    Software development teams typically are focused on a single goal: delivering new, killer features that users love. Driving revenue and usage is core to Agile and DevOps. Yet without motivated, productive people, you can forget about building good software.

    Heightened competition requires companies to go the extra mile to develop and retain employees. Here are several ideas for team-building and personal development, while still pushing an awesome product out the door quickly.

    Focus on high performers first

    Struggling employees often receive the most attention and oversight from managers, but it’s really the top performers who should get the majority of the attention and development opportunities. While modern learning and development methods can be less costly than traditional conferences and seminars, the same philosophy rules: spend the most time and investment on those individuals with the highest potential. Don’t underestimate green developers who are eager to grow; they may not have shown their colors yet, but you can typically see early on if they will with a little push.

    Ditch the annual performance review

    Over the last few years, companies of all sizes are starting to move away from traditional generic performance review metrics and processes. The annual review is nearly obsolete, given the pace of change in business and the fact that employees change companies so frequently. Goals set forth a year earlier may no longer be relevant after six months. Performance review planning is also too time-consuming for busy managers these days.

    Instead, consider a more organic process where the employee and manager visit quarterly, developing mutual agreements and goals for the coming months. The customized approach is more meaningful and real-time for everyone. A useful reference on modern employee retention tactics is “The Alliance,” co-authored by Reid Hoffman, a founder of LinkedIn. The book’s premise: Stop thinking of employees as family or free agents and start thinking of them as allies on a tour of duty. The “tour of duty” theme is highly relevant in software development, where tactics and objectives are constantly changing and the pressure can be intense. As long as the employer and employee are constantly seeking to get the most mutual value out of the relationship, employee retention should not be an issue.

    Offer diverse experiences

    Younger employees, including those of the Millennial generation, typically enjoy working in a flat organization where they can take ownership of projects and feel they’re advancing within the organization. Take advantage of that independent ambition by creating smaller teams and giving leadership roles to those who are ready. Younger employees also covet change, so rotational roles can be an excellent way to give them that diversity in experience while also monitoring their progress for long-term career growth. Mid-level employees often feel the highest level of stagnation due to the typically long process of promotion into senior management, so it’s critical to have a strategy for developing and retaining those positions as well.

    Motivate and grow senior developers

    Organizations often go to great lengths to bring in promising young talent and grow them into senior developers. However, the path beyond for a senior developer often provides a fork in the road, with options to either focus deeper on the technical side as an architect or on the people side as a manager. Executives should support senior developers early in this transition and identify key candidates for each role, and then help them to prepare accordingly.

    Make collaboration fun

    Developers today should be groomed and evaluated for their collaboration skills. There’s no right way to do this, but a good start is by making collaboration easy and even fun for those highly independent people who haven’t had to communicate much with coworkers in the past. Offer simple chat and social media tools for real-time, online collaboration or feedback tools such as TINYpulse, which can mask someone’s identity if they are too shy to share feedback otherwise. Requiring team members to demo their work in progress for colleagues can encourage collaboration and sharin, and boost product quality through timely feedback. Offer perks or bonuses for those team members who show initiative in teamwork and cross-team collaboration. Needless to say, FACs (happy hours) and other offsite opportunities for the team to unwind together also can break down barriers.

    Make innovation a cultural trait

    Measuring innovation isn’t straightforward, but making room for it within your organization is a powerful way to both motivate and retain employees and, ultimately, generate business value. Google grabbed headlines a few years ago when it shared its policy of giving technical employees 20 percent of their hours every month to work on independent research projects. Granting employees free time to work on new ideas is smart, but works best if developers are passionate for the business and will reinvest that time in areas that add business value.

    More importantly, recognize that innovation is not a program but a cultural value that can only be communicated from the top. Senior-level support for innovation, along with free sharing of ideas, should be baked into team processes and communications. Finally, time is a finite asset. If you’re going to give your team some time off for creative brainstorming, don’t penalize them for lower output or require them to work weekends to make up for it.

    Push the soft skills

    This is a no-brainer. Modern development teams increasingly are linked hand in hand with business goals and customer outcomes. Therefore, developers must be able to work effectively with business counterparts and understand the language of the business. Give your developers frequent opportunities to present in front of their co-workers for practice, and whenever possible, the chance to work directly with business units on projects.

    Look to the community

    The days of structured career paths and employee development programs are largely over. Employees want and benefit most by self-learning and exploration with their external communities. This entails giving people leeway to attend meetups, participate in developer contests or attend half-day workshops where developers can interact with others in their field. MOOCs, online degrees and certifications are gaining favor as flexible ways to quickly gain new skills. These informal learning opportunities are much more cost-effective than formal training programs of the past and more relevant. They help employees gain general marketplace knowledge on new development trends and tools, rather than company-specific knowledge and processes.

    Investing in technical skills is imperative, yet developers also to want to feel part of a team and work with someone looking out for their career potential. By paying more attention to developers’ personal goals and the needs of the team, software development organizations gain more stability to do what they do best: develop great products.

    About the Author/Kevin Dunne

    Kevin Dunne picKevin Dunne is VP of Strategy & Business Development at QASymphony.

  • Microservices: Easier Than You Think

    Microservices: Easier Than You Think

    “Microservices are easier than you think and more valuable than you’ve heard.” Those are the words of Ben Gracewood, chief delivery officer at cloud POS and omnichannel retail provider Vend. His company has used microservices to trim a monolithic PHP application, improving performance and changing the way the company approaches updates.

    Approaching Microservices

    Vend is currently used by 15,000 retailers in more than 180 countries. It is aimed at inventory-based retailers—think housewares, fashion, grocery and so on. In addition to the usual POS and payments facilities, Vend handles loyalty schemes, gift cards and online storefronts. The company is based in New Zealand, with offices in London, Melbourne, San Francisco and Toronto. Engineering and DevOps is done in Auckland.

    Its global customer base means there is no maintenance window, and so live updates are essential.

    Vend’s HTML5 and iOS clients include caching and a local database to allow offline operation (the data is subsequently resynchronized), primarily to allow users to keep working in situations where there is no Internet connection. The main system was originally a monolithic PHP application.

    Vend executives had discussed the idea of migrating to microservices for about a year. But when the company’s vice president of Architecture experimented by writing one read­-only microservice that improved performance by orders of magnitude, “This was the ‘a-ha’ moment for us,” Gracewood says.

    Later, when Vend migrated from Rackspace to Amazon Web Services, it used a routing microservice that directed traffic to whichever cloud held that particular customer’s data at the time. That allowed a progressive migration with no disruption for customers.

    Those initial successes showed Vend it should move more seriously in that direction. Nine months later, the company had 12 microservices in production.

    Vend is now adding them at the rate of about two per month, and the monolithic PHP system has been slimmed and surrounded by a cloud of microservices. An Nginix-based routing layer allows existing URLs to be redirected to microservices where appropriate.

    The company has followed DevOps practices from the outset, but its first few microservices were deployed and managed as special cases. Now, both the PHP monolith and all the microservices are within the DevOps tent.

    Adoption Dos and Don’ts

    When it comes to adopting microservices, “It’s never too soon to start,” says Gracewood. “It doesn’t have to be all or nothing,” despite what you might hear from other microservices veterans—everyone has been partway through their journey at some stage.

    Gracewood’s advice is to build your first microservice and do what you have to in the development of your DevOps practice. Then keep iterating.

    Don’t fall into the trap of thinking a microservice has to be 100 percent complete before it can be deployed, he says. Start by developing the minimum functionality required at the outset, and then increasing its sophistication over time. Since a change to a microservice affects a relatively small part of the entire system, the continuous update model is easier to apply to microservices than monolithic applications.

    That point also has an organizational impact: A microservices architecture and DevOps support Gracewood’s philosophy of trusting engineering and development teams to implement the right things at the right time. With monolithic software, a mistake or a poor decision can have wide-ranging repercussions, so considerable oversight is required. But the nature of microservices keeps issues localized, so if an issue does somehow slip through the testing process, it is easier to revert to the previous version.

    Adopting DevOps and microservices does require a certain amount of education, Gracewood notes. Engineering teams must understand the command line, Docker and so on. Making the move calls for “lots of tooling or lots of training,” he says. To that end, Vend has built some custom tools.

    Gracewood’s final tip for organizations thinking of adopting microservices: “Log everything [and] apply metrics to everything,” right from the start. You need to know how people are using your system. In particular, identifying the most heavily used microservices will reveal the areas where efforts to improve performance are likely to yield the best returns.

  • Why Financial Companies Should Embrace Automated Testing

    Why Financial Companies Should Embrace Automated Testing

    The drive to deliver new functionality to customers faster is being felt across every industry, and especially so for financial markets that are under pressure from new market entrants. Adopting agile development and continuous delivery can help financial institutions gain an edge and beat competitors to market, but it’s vital that quality is not forgotten.

    Financial institutions are accelerating to update software and release new products in days or weeks instead of months. That means software must be tested rigorously and quickly. Manual testing simply cannot compete with automated testing when it comes to speed, accuracy and the ability to perform functions repeatedly over time. However, it can be challenging to implement successfully. 

    The Customer is Always Right

    Customer power is forcing banks to improve customer experience. Accustomed to slick, efficient website experiences from such leaders as Amazon and Google, customers now are demanding similar experiences from their banks and credit card companies. Millennials expect easier access to banking, precipitating a shift to self-service, which presents all kinds of new IT challenges for banks.

    When customers don’t like their online banking experience, they will simply choose another provider. A full 18 percent of millennials switched their primary bank in the last 12 months, according to a recent Accenture survey. When failed or flawed software gets into the customer domain, the fallout can be very damaging and expensive. Think: lost sales, disgruntled customers, bad PR and a massive price tag to fix the problems.

    Test Automation a Solid Foundation

    Introducing test automation isn’t just about finding defects more quickly and efficiently, though it will do that. It’s also about shifting the burden of regression testing and freeing manual testers to focus on issues such as exploratory testing, usability and penetration testing, where they can add the most value.

    To implement automated testing successfully, financial institutions must devise a long-term plan that dovetails with their business objectives. Having a plan—and sticking to it—outweighs the importance of getting C-level support and winning a huge budget for automated testing. Without a plan, the most well-intentioned objectives can get rejected by senior management, stalled by other forces and, ultimately, forgotten.

    Automated Testing Misconceptions

    The plan should include a robust dismissal of two popular misconceptions about automated testing. The first—and bigger—one is that automated testing will produce instant cost savings, as fewer resources (mainly of the personnel kind) will be needed to perform testing.

    Over time, automation will cut costs. But cost should never be the main factor when considering automated testing. Applying test automation greatly outweighs all the negatives of manual testing (time-consuming), but it also opens new doors for more sophisticated testing and, hence, the competitive advantage.

    The second misconception is that automated testing is a one-time only exercise. Reality proves that automation is always going to be an ongoing process. Automated testing should be treated as (yet) another development activity: You write the production software and you write the software that tests the production software.

    Overcoming the Challenges

    Financial institutions face a threat from newcomers to the market, unencumbered by legacy system baggage and physical branches. They are offering disruptive products and new business models. How can existing financial institutions compete?

    It obviously makes sense to include the business and marketing teams in the development process to develop new solutions for customers. Extend the DevOps mindset to break down those silos. A united team that includes test and marketing alongside developers can ensure that automated tests are well-designed and focused on business aims.

    Pulling together to design and test new ideas can enable financial institutions to reinvent themselves and innovate. Embedding test automation in everything mitigates risk and increases velocity and quality. It can deliver the data businesses need to make the right next move.

    Long-Term Vision, Short-Term Plans

    Fast feedback is paramount to make the right business decisions, but financial institutions must cater to existing legacy systems and integrate new software deliveries from a range of vendors. Without test automation in place, it’s simply not possible to integrate deliveries, test them and reject them as quickly as possible if they are wrong.

    The reality is that organizations must be able to quickly introduce new tools and technologies, because agility and innovation go hand in hand, but the impact on legacy systems must be repeatedly gauged. Test management tooling should be fluid and extensible to cater to this diversity. To accurately measure quality and risk in real time, test automation must be dynamic and flexible.

    Failure to embrace automated testing will leave traditional financial institutions exposed and in danger of being swept away by the new wave of lean, agile, IT-focused competitors.

    About the Author/Viktor Clerc

    viktorViktor Clerc is product manager for testing applications at XebiaLabs, a provider of automation software for DevOps and Continuous Delivery helping companies to accelerate the delivery of new software. You may reach him at vclerc@xebia.com.

  • IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    Thousands of people descended upon Las Vegas last week for the annual IBM InterConnect conference, where IBM shares its vision with customers and developers and makes big announcements. One of the biggest things Big Blue unveiled was BlueMix OpenWhisk, an event-driven programming service designed for a serverless computing environment.

    OpenWhisk uses an event-driven model, automatically executing code in response to external events such as incoming sensor data or designated triggers. (Event-driven programming is also called serverless programming, because the events themselves more or less become the foundation on which the programming is built.)

    Al Hilwa, program director of Software Development Research for IDC, declared the BlueMix OpenWhisk announcement to be one of the most interesting revelations at the IBM InterConnect conference. “This is IBM’s play in the hot area of serverless back-end computing supporting an event-driven application model like AWS Lambda, Google Cloud Functions and technologies from players like iron.io,” he noted. “This is the new face of PaaS, where developers do not have to worry about infrastructure.”

    I recently wrote that advances in DevOps increasingly seem to marginalize the “Ops” part of the equation, essentially making it obsolete: I noted that what you’re left with essentially is developers with the processes and tools to automate the infrastructure back end. Technologies such as containers and services such as AWS Lambda simplify greatly the process of programmatically generating, modifying and maintaining the underlying infrastructure.

    As I summed up in that article, though, Ops won’t really go away. Advances in DevOps and technologies such as serverless computing simply free operations teams. They can spend less time putting out fires or maintaining mundane configurations and focus more on big-picture issues that improve performance and help the company innovate.

    OpenWhisk is evidence of that future. It has the potential to transform IT and accelerate DevOps even more. Developers can develop and deploy applications faster and more seamlessly without the need to worry about the servers or middleware traditionally required. OpenWhisk will handle the necessary code.

    IBM suggested developers can use OpenWhisk to create microservices-based applications, where each individual task or component is developed and maintained separately. Different teams can operate in parallel on their individual elements.

    OpenWhisk joins other serverless computing platforms including Amazon’s AWS Lambda and Google’s Google Cloud Functions. As Hilwa pointed out, there are also emerging players such as iron.io. The unique value that OpenWhisk brings to the table is that it is integrated with the BlueMix platform, which means developers have immediate access to all of the apps, analysis and services BlueMix has to offer.

    IBM will open source the codebase of OpenWhisk itself. That isn’t a surprise, since BlueMix itself is based on open source code and IBM is a major proponent and benefactor of open source projects. The true potential of a tool such as OpenWhisk can be realized more quickly with the community at large helping to evolve it, but IBM can continue to act as consultants and provide deeper services for customers to help them maximize the value of OpenWhisk.

  • How DevOps Prevents DDoS Attacks

    How DevOps Prevents DDoS Attacks

    Distributed denial of service (DDoS) attacks are some of the most pervasive and difficult attacks to prevent. The attack uses many distributed endpoints and/or systems to flood a web domain, application or service with excessive service requests or application calls. There are limits to the amount of bandwidth or the number of service requests or application calls that the associated web-based resource can handle at any given time, and when attackers using these requests or calls overwhelm these Internet resources, service is denied to genuine users who need legitimate access.

    “These attacks are designed to either melt down your network or squash your applications and servers. Industry experts identify them as L3/L4 attacks and L7 attacks accordingly,” says Stephen Gates, principal SE and senior technical expert at NSFOCUS IB, a global provider of network security and advanced analytics. L3/L4 and L7 refer to three of the seven layers in the Open Systems Interconnect (OSI) reference model: L3/L4 refers to the network and transport layers, respectively, while L7 refers to the application layer.

    These DDoS attacks are a big concern because they prevent users from accessing services and websites to conduct their business, which impacts user experience, employee productivity and a company’s bottom line. “The largest L3/L4 DDoS attacks on record exceeded 400Gbps in size,” says Gates. “Organizations all over the world regularly feel the effects of L7 attacks,” amounting to a lot of service disruption for a lot of businesses.

    Handling DDoS Attacks with Rugged DevOps

    Although Rugged DevOps can’t defend against L3/L4 attacks, it could help mitigate L7 attacks, Gates notes. Since L7 attacks are so common, a Rugged DevOps approach that fixes many—if not most—of them is an important tool can be an enterprise’s arsenal against DDoS. For it to work, Rugged DevOps must address the several types of vulnerabilities that appear in development of applications that make successful L7 DDoS attacks possible.

    Most of the vulnerabilities susceptible to L7 DDoS attacks unfortunately permit unwanted user behavior in or in conjunction with applications that are accessible via the Internet. “For example, if a client machine continues to do the same thing over and over again (repetitive HTTP GET), this would be indicative of an unusual client behavior,” explains Gates. An HTTP GET is a request to the HTTP (web) server for data. Applications must apply methods for disregarding the several forms of unwanted behaviors.

    Attackers can also send DDoS attacks against the application layer by using malformed packets to leverage weaknesses in ill-coded software. Packets are a means for encapsulating data into packages or units for transfer across packet-switched networks. “For example, if an attacker launched the ApacheKiller script against a vulnerable version of Apache, the application would completely fail to operate,” illustrates Gates. Applications frequently display these and other vulnerabilities to specially crafted attack packets.

    How Rugged DevOps Can Help

    Developers could avoid many of these kinds of application coding errors and vulnerabilities early in development by applying Rugged DevOps, which can catch and fix security holes early in the software life cycle. “Then they will likely not propagate into later versions of the application or the plugins riding on top of these applications,” says Gates.

    Running penetration tests on software early in the development process is one way to thwart holes that enable L7 DDoS attacks. When coding missteps are uncovered early in the process, developers can fix them early, before they become part of the software. Tools such as Gauntlt, Mittn and BDD Security are examples of software testing tools that developers can use inside the DevOps shop.

    Failed tests require a response. One such response is to automatically fail to build the software when the software fails the test(s). If development can’t move forward without fixing the security holes, the security holes will be fixed.

    There are well-worn methods that developers can rely on to fix the most common, most threatening application security vulnerabilities. Developers should not have to do a lot of digging to uncover these methods. Many organizations and resources such as the Open Web Application Security Project (OWASP) clearly set these approaches apart and label each of them on their own distinct Web pages. This SQL Injection Prevention Cheat Sheet is only one example.

    DDoS and other forms of attacks are, unfortunately, a part of life. Being able to mitigate an attack before it can occur is a goal. Rugged DevOps is one way to help make that goal a reality.

  • Webinar: From Healthchecks to Real-time Metrics – Clever’s Journey

    Webinar: From Healthchecks to Real-time Metrics – Clever’s Journey

    Clever is an identity and authentication SaaS product serving millions of students, in tens of thousands of schools. Mohit Gupta, Product and Engineering Lead for Clever’s infrastructure, is responsible for the platforms that keep the product running every day.

    Most people are familiar with healthcheck and polling-based monitoring and alerting systems. Clever chose to go a different route – instrumenting metrics throughout their stack, from infrastructure up through custom metrics from the microservices behind the app. Mohit will discuss why Clever chose this direction, and why it’s important for operating SaaS products.

    John Bruce, Head of Solutions Engineering from SignalFx, will discuss how SignalFx was built for the world of DevOps and microservices, and demonstrate how customers like Clever use it every day.

    What you will learn:

    • Why you should use metric data for monitoring and alerting
    • What kinds of metrics really matter
    • How to reduce alert noise through analytics

    Recording

    Slides


    [seoslides embed_id=”3f9ad8b1b03c” script_src=”https://devopsy.kinsta.cloud/embed-script/healthchecks-real-time-metrics-clevers-journey/13866/” overview_src=”https://devopsy.kinsta.cloud/slides/healthchecks-real-time-metrics-clevers-journey/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”From Healthchecks to Real-time Metrics – Clever’s Journey” /]

  • Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    “Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.

    There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.

    This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.

    Security Questions to Ponder

    Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?

    Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.

    There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.

    It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.