devopsy.kinsta.cloud

Tag: mvp

  • Accelerating MVP Development Performance Through DevOps

    Accelerating MVP Development Performance Through DevOps

    The core concept of minimum viable product (MVP) is to get maximum learning and understanding regarding what customers want about a product. Learning and understanding is a continuous process requiring a development process that is incremental in nature. That makes DevOps a favorite for CIOs and everyone else who dabbles with MVP development.

    How can DevOps help in accelerating MVP development?

    Continuous Updates

    Any MVP is built with assumptions about customer preferences in mind. Developers may have a deep understanding of what customers want, but they have no solid proof. The MVP “tests the waters” and measures the depth of the customer reaction. Developers then can develop and refine the application further, depending on the customer responses.

    Building an MVP that can be easily updated is no easy task, however, especially if the MVP juggles too many APIs that collect data from heavy databases. Traditional application development tactics may not work here. It is here that DevOps makes a difference. Its continuous integration and continuous delivery (CICD) tools ensure that any application or MVP can be easily updated according to dynamically changing scenarios.

    In other words, DevOps can help accelerate MVP development.

    Microservices

    Microservices is a concept in DevOps where the application is broken down into several loosely held parts. For instance, when a social media app is being built, its various components such as a newsfeed, stories, chabot, etc., are built separately as microservices.

    The prime benefit of microservices is that the updating, maintenance and bug-fixing process is simplified and easy to manage. For MVP, this translates into easier editing of feature sets to meet changing customer preferences. Also, it breeds an organizational culture of collaboration in which developers as well as applications have to mingle with each other to perform better. Such a collaborative environment is key to accelerated development of MVP.

    Extensive Automation

    DevOps and automation go hand in hand. In fact, zero-touch automation is deemed to be the future of DevOps. Right from continuous business planning to feedback optimization, there is plenty of scope in MVP for automation.

    Needless to say, automation drives operational agility. It also quickens the pace at which routine tasks are done. DevOps adoption for MVP development means developers can make more features and deployments faster within a short span of time.

    A Scalable Foundation

    Infrastructure as code, or IAC, is a key DevOps practice. It works by configuring servers automatically, especially cloud-based servers. IAC works by creating a single configuration file for all the servers. It is like a single template of configuration that can be cloned easily for several servers.

    As a result, DevOps allows applications to quickly ramp up their server capacity in a flash. The same goes for MVP: When the MVP gets the nod of consent and is mature for advanced development, the same server setup can be used as a foundation for upscaling the resources. Also, the same configuration file can be used to set up as many as servers as you want. What is the result? Cloud servers up and ready to use without loss of time.

    DevOps and MVP Development — A Formidable Combination

    Deploying a MVP is an integral part of the development process. DevOps, with its microservices and IAC approach, can help accelerate the pace at which applications are developed and deployed. Additionally, CI/CD tools ensure wide-scale collaboration among teams.

    Integrating a DevOps culture right from the MVP stage of an application will help in the development of a final product that is bespoke to customer requirements. Even if the customer requirements are different, microservices help to quickly modify them and update the application without significant downtime. To sum it up, DevOps is the perfect approach to accelerate MVP development.

    — Dhaval Sarvaiya

  • Minimum Viable App Doesn’t Mean Minimum Security

    Minimum Viable App Doesn’t Mean Minimum Security

    It’s estimated that the total market for mobile apps will hit $143 billion this year. A big portion of that budget will be enterprise mobile app development. By next year 25 percent of enterprise IT budgets will be aimed at their mobile app efforts. Yet, despite these efforts, most enterprises are still falling behind in their mobile app development pipelines by 12, 15 and even 20 weeks.

    To help clear that backlog and meet their internal mobile app demand, more enterprises are focusing on delivering the mobile apps with the features that hold promise to produce the most return on their efforts; that is, the apps that people likely will use and will do the most, for the least investment, to help to improve their daily work lives and productivity. Or, this minimum viable product (MVP) is the minimum required in an app to prove out its app concept.

    But when moving apps out quickly, enterprises risk skimping in areas of quality and especially security, which can pose a risk to data that should be handled with care, notes Isaac Potoczny-Jones, research lead, Computer Security with security research and development firm Galois.

    “There’s definitely a lot more development in mobile happening,” says Potoczny-Jones. “I think the [security] best practices in mobile aren’t as well-developed as best practices for the web. I think that’s getting a little bit better, and there’s a very fascinating challenge with security [with MVP] because security is a non-functional requirement.”

    Of course, apps must be developed with good mobile security—including app password management, server side controls, cryptography and other best practices—in mind. The OWASP Top 10 Mobile Security Risks provides an excellent overview of common mobile risks and associated mitigations.

    One of the challenges with mobile security testing is that the best practices and associated processes are not well understood by most, at least not yet, and quality mobile security testing tools are not deployed in many organizations. Plus, those organizations using some of the common mobile security testing tools find that they don’t always suffice and they often have to build their own automated toolsets.

    The risk with fast-tracked MVP apps is that they never get anywhere near a security test before being shipped to production. But these apps—just like any other apps that get near enterprise data and networks or may access sensitive, confidential or regulated data—must be vetted, threat modeled and tested (static and dynamic app testing), along with the usual quality tests. And with MVPs, it’s just as important that this testing be an integrated part of the process from the beginning.

    The best way to achieve this, of course, is through awareness and secure code training with developers.

    Companies may want to consider creating an MVP development guide that could detail security considerations for the MVP. Such a guide could help developers determine what security best practices to follow, as well as what apps need to be sent to the security team for reviews—and when.

    Potoczny-Jones says there’s no reason, except for maybe carelessness, why MVP apps are being built with minimum security considerations, as most lean development methodologies have security testing built into their processes. “Once you get these teams to include security testing being a part of [what they consider] ‘being done,’ which I don’t think a lot of people have, then they’re going to do the right things. You’re either going to start to build security either into the user stories or the acceptance testing,” he says.

    That’s for sure, and it shouldn’t be left to the end of the development process. “You can’t leave it to just be at the end of the process. If you leave security testing toward the end, naturally your schedule is going to slip. You’ll find that there’s a lot more work to do. Then you’ll be in this unfortunate position of having to decide whether to fix things and let the schedule slip, or choose to let something go out the door that’s not secure,” Potoczny-Jones says.

  • Starting with DevOps from Day 1

    Starting with DevOps from Day 1

    The Not So Minimal MVP

    In the ever evolving startup space, developers often skip crucial steps in their haste to get to market. Even more so, in the dynamic app development market, the common notion of an MVP (minimally viable product) allows developers to iterate versions of their product based on issues and feedback. Seen in the context of horizontal technologies like Facebook and Twitter, the iteration period is where the real magic happens. Historically, the first versions at the “MVP” stage were bare-bones. That was then, this is now.

    As apps get better, people’s expectations are getting higher. This puts more pressure on startups to have an impactful product from the get-go. Features that used to be new and fascinating are now the expectation, so startups must adapt to have a strong 1.0 as a foundation for iteration. I recently saw an ad for a company calledCircleci whom I know little about, but the tag line was brilliant; “Launches are dead, long live iteration.” Apple and Microsoft may still have ‘launches’. Startups iterate.

    One way Zipline achieved a high-standard first version was by adopting DevOps via Rackspace DevOps Automation Service from our inception. Instead of migrating our app over to a more mature platform after many iterations, we decided to make the investment early. Here are just a few reasons how adopting DevOps from day one can help position a startup on the cone of a rocket ship:

    1. Understanding Scalability

    There’s a line of thinking that goes like this: First comes product, later comes scalability. We strongly disagree. When people hear the word scalable, they think upwardly increasing capacity and size. So it can wait, right? For startups, downward scalability is just as crucial. While most startups view DevOps as an option for the future, we found success by leveraging DevOps from our inception. Instead of waiting to implement a mature infrastructure like DevOps, we looked for partners that could give us access to managed services typically only available for big companies. We found success with large scale systems that were downwardly scaled to match our business need. DevOps gave us an opportunity to work with systems that were ahead of us in terms of technology and culture. Startups who view their product as agile, dynamic and iterative, but DevOps as only a static-run environment are making a huge mistake.

    2.Understanding Culture

    Hiring and retaining top tech talent is difficult –even more so for startups. But we noticed something profound as we grew our development team from one to seven: Talented engineers who interviewed with us expected our infrastructure to be novice. When they realized that our DevOps infrastructure rivaled that of the big company where they previously worked, their minds were put at ease. I’m not saying it always closed the deal, but it signals to a growing team that they are part of a winning culture. Building a winning culture starts from day one.

    3.Understanding the Cost of DIY

    Most developers capable of writing quality code are also capable of creating an environment to run the code. The cost seems so innocent at first. For a bootstrapping startup, common sense says “do it yourself”. Again – wrong.

    Nothing is more costly for a startup than distraction. Every minute should focus on your unique competitive advantage. I’ve never heard anyone say, “I use this technology because of their awesome DevOps.” What makes your company great? Strong DevOps for startups should eliminate distractions, sharpen focus and accelerate code commits.

    4. Understanding Collaboration

    Walk into most mature tech companies and you’ll notice something: The development team and operations team are separated into different spaces. Startups should exploit this vulnerability to gain a competitive advantage. Collaboration in small startups should be instant and in real-time. At Zipline, deploying DevOps from day one promoted a culture of open communication across all people involved in delivering our application. According to the Rackspace DevOps Automation Survey, 41% of organizations have seen better collaboration amongst project teams and 35% have seen more accountability across developers and operations for getting apps to market after deploying DevOps. Running a collaborative system allows us to focus on elevating our product in innovative and creative ways.

    5. Understanding Iteration

    Every system at a startup should iterate constantly. Take something mundane, like bookkeeping. If your system of keeping books isn’t better on Friday than it was when the week began, then you failed. The death of a startup can occur quickly. Iterate or die. So ask these simple questions every Friday, “Is our DevOps better than it was on Monday? If so, how? If not, what can we do to change it next week?”

    About The Author/Kirk Bowman, JD

    Kirk Headshot Bowman is the founder of Zipline Labs, Inc. A life-long entrepreneur, Kirk loves applying the mental rigor he honed as an attorney to creating innovative businesses that shift perspectives and evolve behavior. His endless curiosity and capacity for complexity unearths opportunities in the least likely of places. Now, he’s focusing his thought leadership in the financial sector. As founder of Zipline, Kirk is exploring how people relate to money and how technology can support an evolution to financial systems that are more social, more connected and more human. A master storyteller, Kirk is a compelling voice when evangelizing for his belief that if we can shift the way we feel and behave around money in both our personal lives and our work, we can create a better human experience.

    Connect with Kirk on Twitter: @kirk_bowman Connect with Kirk on LinkedIn: LinkedIn

  • Clearing through the app backlog clutter

    Clearing through the app backlog clutter

    Development and operations teams today are under more pressure than ever to develop apps the business needs to make its workforce productive, its partners connected to the resources they need, and to deliver the apps to the marketplace that will make it competitive.

    The number of production hours for development is at a precious premium as demand for apps soar and resources remain tight. According to Gartner, the demand for enterprise mobile apps alone will be a $40 billion market by 2016.

    Of course, the inevitable happens and the list of designed applications gets backlogged. They get caught-up in budget requests that drag on, and then they get caught in the long list of requested apps in the development queue. A recent survey commissioned by PaaS provider OutSystems found that 85% of enterprises surveyed had an app backlog, with about half having backlogs of 10 to 20 apps.

    App Backlog, agile and DevOps

    Sure, development and operations teams move as quickly as they can to meet the enterprise demand for new applications, but when there is any deep app backlog, there is the potential for business costs when it comes to lost opportunity, untimely product development, and future missed sales. In a time when agile IT means competitive advantage, any amount of latency that can be cleared from the application backlog is crucial.

    Agile development approaches and agile IT departments tried to remedy some of these issues, but didn’t go far enough. Fortunately, DevOps picks up where agile left off in the evolution of enterprise development. And in the face of agile IT, continuous integration, continuous deployment, and the rise of DevOps – operations, development, and infrastructure bottlenecks become minimized – and infrastructure and applications move more quickly, and existing applications are iterated more swiftly.

    Of course, DevOps itself, can help to accelerate app deployment, in addition to continuous integration and continuous deployment efforts. And all of the associated deployment automation tools and deployment processes are essential to eliminating manual waste so teams can focus on pressing business demands. This waste can include time burnt on manual process, manual testing, and the configuration of the software development environment.

    DevOps-driven organizations have shorter app backlogs. A recent CA Technologies study in fact found that organizations embracing DevOps report a 17 to 23 percent improvement in certain business outcomes, such as increased revenue, and faster time-to-market.

    Cloud architectures and easier to master development languages also help, not just infrastructure services, but also platforms that help to free up operations teams and developers to focus on the applications that need to get out yesterday.

    Even with DevOps practices in place and automation running full throttle, the business development teams still find themselves having to make difficult choices about which apps to build and deploy. Not all of these apps will survive, in fact, many apps will go unused and dormant. This means that a lot of time can be lost developing apps people don’t want to use, or are too cumbersome to bother to use.

    Turning to the Minimum Viable Product

    In addition to DevOps, development teams are also turning to approaches such as the Minimum Viable Product (MVP) as a way to help identify apps that have real user demand and those that do not. Essentially, the MVP app is an app that consists of only the essential. The MVP provides the essence of the app and what users need to get done and no more. The MVP is a potent way to provide the essential attributes of an app to see if users embrace it before building the app out further. If the app is used, new features can be added over time.

    Not everyone is convinced that the gains made against app backlog aren’t necessarily illusion. David Mortman, distinguished engineer, says “DevOps and MVP both have the ability to create the impression that you are solving backlog issues. This is because in both cases you are enabling the development organization to get that first release as early as possible and then to keep iterating it and adding features as the dev group goes,” he says. “This however may not get you to a particular defined endpoint any faster since regardless of the organization there are always resource limitations.”

    Still, “One advantage of DevOps and Agile is that they let you interweave development cycles so multiple apps can be worked on faster and each can be incremented more quickly. They also make it easier to adjust priorities between apps more quickly and more quickly identify apps that aren’t meeting the business needs and either deprioritize or eliminate the app before overinvesting in its development,” Mortman adds.

    There’s no doubt, based on my discussions with enterprises, app backlog repeatedly comes up as a serious challenge to competitiveness. But by embracing continuous integration, deployment, and MVP development, organizations can go a long way to help clear through, at least the initial stages of their app backlog. What is your organization doing to help clear app backlog? We’d like to hear your experiences and lessons learned.