devopsy.kinsta.cloud

Author: contributor

  • Mastering the Art of Cloud Migration

    Mastering the Art of Cloud Migration

    Cloud computing has come a long way over the years. Yet, only a few enterprises have managed to master the art of cloud migration. The secret to a successful migration lies in a well-defined, phased and iterative approach that not only streamlines the process but also accelerates the outcome. Here is one road map to assist others in transforming their migration journey:

    Phase 1: Plan

    Benjamin Franklin once said, “If you fail to plan, you are planning to fail.” Planning thus becomes the most critical part for a cloud migration program. Key focus areas in this phase include program management setup, portfolio analysis and cloud architecture and operating model layout.

    • Program management setup: The program management office (PMO) plays a major role in managing all aspects of the planning phase, from facilitating strategy building to program governance and benefits realization. The PMO ensures strong leadership commitment, sustained change management, program strategy alignment, rigor in project execution and decision-making governance.
    • Portfolio analysis: Analyzing the application portfolio helps in providing adequate representation of applications in scope. Application dependency information helps plan the sequence of application migration. It further pushes the business case for enterprise cloud migration.
    • Cloud foundation and operating model layout: The cloud foundation is comprised of landing zones. A landing zone is a standard set of secured cloud infrastructure with built-in policies, standards, guidelines and centrally managed services. Creating a strong foundation through landing zones is crucial for a scalable and sustainable enterprise AWS cloud model. As cloud computing becomes the paradigm for delivering business, technology operating models need to evolve and add more cloud-centric capabilities. A cloud operating model is the framework for putting core elements together in a more agile, productive and valuable way.

    Phase 2: Assess

    During the assessment phase, applications are analyzed in detail for future disposition. A cloud architecture and cloud operating model help lay the foundation for migrations. Consider the following:

    • Macroanalysis: Macroanalysis of applications, leveraging a proven cloud readiness and assessment framework based on business value, IT efficiency and cloud suitability ensures a clear migration road map. It also identifies enterprisewide concerns around security, networking, technical, operational, organizational, regulatory and financial.
    • Microanalysis: With the macroanalysis already performed, it is time for the deep dive. Microanalysis facilitates the understanding of current state architecture and defines cloud architecture based on patterns developed during macroanalysis. It concludes with the preparation of the detailed migration plan and effort estimates.
    • Cloud foundation and operating model design: The design should adhere to enterprise security and networking policies. Account and VPC structure needs to be designed based on cost allocation, resource management and ownership and security and compliance isolation. People, process and technology are the core elements of the cloud operating model. These should evolve to achieve cloud operating model goals, thereby increasing the value for the business and operations. People skills and experience are geared toward becoming more cross-functional, spanning a wider range of service components and use cases. Processes are then realigned around services instead of technologies, while tools and technologies are selected for effective implementation and automation of processes.

    Phase 3: Migrate

    During this phase, foundation cloud architecture and operating model are implemented, and the first set of applications identified as quick wins are migrated. The set should include a varying complexity of applications across different business units. Also, during this phase, it is important to take a proactive approach to change management. Consider the following:

    • Cloud foundation and operating model implementation: This step enables setting up landing zones including accounts, VPC, network connectivity, IAM Roles, policies and deployed workflow. Shared services and tools are also provisioned. In the cloud operating model, key processes are rolled out and teams are mapped to the new cloud-centric roles. This is followed by rolling out of subsequent processes leveraging the key learnings from the existing implementations. This ensures seamless integrations with current systems through the installation of selected tools.
    • Initial migration: The first set of applications is migrated as quick wins. The successful migrations help understand the portfolio and add to the confidence of the applications team. Importantly, it also lays down the foundation for repeatable migration patterns.
    • Change management: Effective change management is pivotal to the success of a cloud migration program. Change champions are involved to ensure co-creation of the future road maps and smooth cultural shifts. Continuous knowledge sharing and training is performed to evolve skills and include them in the transformation journey.

    Phase 4:  Scale

    After initial application migration, it is time for enhancing scalability and accelerating the cloud migration journey. While shifting the focus to scalability, it becomes important to keep a tab on cost and security. Consider the following:

    • Large-scale cloud migration: Harnessing the migration factory model is the best approach to target large-scale migrations. Based on the migration pipeline and supported by best-of-breed tools and specialized core/flex teams, it brings reliability and efficiency to the process.
    • Operating model optimization: Costs can escalate quickly. It is therefore essential to keep a check on it and optimize through policies, processes and moni­­­toring. It requires streamlining financial management by ensuring standardized tagging on all cloud resources.
    • Hybrid cloud model optimization: During this transition phase, both on-premises and cloud models are managed. The cloud model is further enhanced and optimized based on new services and tools.

    DevOps Automation – The Key Ingredient

    Cloud migration is a great time for enterprises to rethink their operational processes and improve the efficiency in managing and administering their portfolio. DevOps automation helps address the needs of a successful cloud migration while improving the operational efficiency of the services. This includes both infrastructure and application deployment automation. Additionally, standard templates and scripts significantly accelerate the buildout of future environments. DevOps also brings a number of business benefits including repeatability, auditability, significantly lower deployment risks and faster iteration cycles—all crucial to improved operational excellence, better security posture and improved competitive advantage.

    About the Author / Aarti Sahni

    Aarti Sahni is a technology leader with a wealth of experience in applying technical and operational expertise to create business value. Aarti’s expertise spans Practice Management, Cloud Computing, Architecture, and Program Management. In her current role at Virtusa, Aarti contributes to business growth by leading a number of pursuits and practice competency development. She also oversees several cloud programs ensuring desired outcomes for clients. Aarti has led a number of large transformations including cloud migrations, DevOps and cloud operating model to drive revenue, reduce costs and increase productivity. Aarti received a Master’s in Computers Application from Delhi University and completed an Emerging Leader Development Program at Columbia Business School in New York. Connect with her on LinkedIn.

  • Understanding the Mobile DevOps Process

    Understanding the Mobile DevOps Process

    In today’s current technology scenario, mobile app developers are always on the lookout for the latest IT innovations to stay on the competitive edge. To make the process of developing mobile apps more efficient, mobile service providers have adopted mobile DevOps.

    Mobile app development adopts the latest trends, technologies and tools for developing intuitive mobile application across different platforms as well as industry verticals. There are many mobile developers who are experts in the development of hybrid and native mobile applications across the platforms for end-to-end mobility, such as iOS, Android and Windows. Service providers aspire to achieve the business objective of the clients through leveraging people, processes and the latest technology.

    Why Mobile DevOps

    There are so many discussion and articles on mobile app development and how mobile DevOps practices could be integrated, adopted with existing processes and even how to use efficient resources that are beneficial for organizations. However, little has been said about why mobile DevOps could make a difference to companies that strive to enable their IT, development and operations to integrate with business goals.

    DevOps is vital for modern app development and delivery. However, leaders in the mobile application development and IT operations should address the unique collaboration, testing the release and analytics needs of mobile DevOps environments.

    Mobile DevOps for a Mobile Apps Developer

    The mobile DevOps discipline needs important business and technical decisions to be usable and to provide value for organizations. To get all critical pieces together and allow continuous mobile DevOps workflow, potential problems and bottlenecks should be identified. Nevertheless, mobile DevOps has its pros, as well.

    For a mobile developer to win the loyalty of mobile users, it must ship the right applications to the right customer at the right time. One has to continuously ship high-quality software and continuously listen and learn from users, providing them features before they know that they want them. Agile development methods are not enough; to win in mobile application, a developer needs mobile DevOps. It combines great automated tooling with a “continuous everything” culture.

    The Pros of Mobile DevOps

    Mobile DevOps has a number of advantage, including:

    • Shortens release time. DevOps, it’s been said, is about collaboration across teams, something that was not managed properly with the old waterfall practices. Actually, mobile DevOps is more than that. The simplified processes, when operations and development come together, could enable organizations share information between the teams and others and considerably shorten the time from the design-development phase to the actual release. Iterative cycle during development enable more frequent deployment of code, get new regressions tested, verified and released faster than regular phase-by-phase process. Mobile DevOps offer a faster path of fixing occurring problems with the product. Once enhancements and features implemented for each build are done, continuous integration with the right test setup provide a faster solution to problems.
    • Enables creation of better applications. More time spent on making new features, advantages and benefits for users simply are enabling the creation of better user experiences. User experience is the true differentiator today in the competition of the mobile apps popularity. Only those that enable delivery of experiences that users expect could remain in the competition. One of the most important things in doing DevOps is enabling instant feedback and reporting, transparent visibility to development and regression testing is paramount. This provides the mobile team an easy way of troubleshooting issues faster and fix, refactor and optimize user experience.
    • Saves time and make use of efficient resources. Faster features delivery, new build and updates are achieved when operation environments such as development, staging and production are stable and the operating environments work easily for development. This itself makes the whole mobile app development process more productive and helps maximize business advantages. One enabler of mobile DevOps is automation. Automation is available from source code management to testing and development tools and further to actual mobile app monitoring in production.
    • Provides multiple tools options. There are hundreds of thousands of tools that mobile applications are developed with daily. For any kind of feature, there should be a tool that could help build, test and deploy a certain part or feature of the app. Nonetheless, for good reason, some tools are used commonly by the mainstream. Most of the tools used and mobile DevOps processes that establish mobile DevOps core facilitate continuous integration, continuous release as well as continuous deployment. Part of the process is app release automation tools, which help up packaging and deploying app from development to production using automation. These tools help mobile DevOps flow to produce capabilities for implementing continuous delivery for even huge number of releases. Release management tools enable organizations to plan and to execute releases, offer a single collaboration portal for all stakeholders and provide traceability for a release and its components across all the build and delivery pipeline stages.
    • Could dodge inefficiencies and bottlenecks. The major idea behind Mobile DevOps is to make things transparent and efficient, boost internal communication and help in building better products or applications. When mobile DevOps practices, processes and tools are in line, several bottlenecks and inefficiencies could be avoided, such as:
      • Inconsistent development environments
      • Stability and maturity of workflow
      • Manual interventions
      • Lack of operational practices
      • ‘Old way’ and ‘new way’ integration
      • Competing/misaligned procedures and lack of ownership
      • Old-fashioned or manual testing process.

    Mobile DevOps is capable of transforming how an organization handles the development process for the better. It is no wonder  it has become the way of the future for mobile organizations. The DevOps approach principle puts emphasis on people and culture above tools and processes; thus, bringing business owners intimately to the design process can boost the success of the process. Organizations have to embrace a combination of collaboration and integration tools from both parties. Seamless interaction unlocks full benefits of the method and could ultimately contribute to overall business and operational success.

    About the Author / Drumit Shukla

    Dhrumit Shukla has been working as Business Development Manager in a software development company named TatvaSoft since 5 years. He is profoundly skilled and well experienced in providing software development services on various technologies ranging from Microsoft .NET to JAVA, Salesforce, BizTalk, SharePoint, PHP, Open Source, iOS, Android, Pentaho and more. Connect with him on LinkedIn.

  • How Data Drives the Business of a Clean Energy Company

    How Data Drives the Business of a Clean Energy Company

    Imagine using kerosene lanterns to light your way into the evening, at home so you can cook, read, shower and the kids can do homework, or outside to keep a business or medical center open or play night games in a park or field. This is life in undeveloped nations. Not only is the light source insufficient, but burning kerosene is harmful to individual health and pollutes the air.

    These issues are important to the team at BBOXX, a new generation utility company that develops clean renewable solar energy products for developing countries. Its team has developed its own “Battery Box,” a solar-powered battery box that powers lights and appliances for rural Africa—providing clean energy for numerous products and appliances including TVs, lamps and mobile phones and any other item that lights up or needs to be powered.

    BBOXX describes itself as a service company, not a technology company, and as such focuses on being a data-driven company, capturing customer data, analyzing and manipulating it to provide better services and to continue to improve the battery box.  Customer data is critical to its overall success: Knowing how and why customers buy and use the battery, when they use it, length of time … there are a number of data points that help BBOXX understand the customer. In addition, BBOXX needs to monitor the batteries to ensure they’re working properly, help maintain connectivity and disable units, if need be.

    BBOXX’s development team captures data by remotely monitoring units. They are able to access data that is being sent from sensors via a 2G network and through the Amazon Web Services infrastructure into the cloud. Once the raw sensor data is in AWS, it is then stored in a database designed for metrics and events. From here, they are able to analyze it, provide business dashboards, generate predictive maintenance alerts and notifications and predict and find interesting business trends such as energy consumption spikes during soccer events, for example.

    In addition, the team at BBOXX can also correlate and aggregate usage information, which helps them upsell additional power capacity based on upcoming events. For example, a football match between Kenya and Zambia increased demand for more energy to support extended viewing times.

    Becoming a data-driven business meant that BBOXX needed access to real-time data at its core, which had another set of challenges:

    • Securely monitor a distributed set of devices across low bandwidth 2G networks
    • Provide real-time 24-7 monitoring to a distributed team who expects the data to always be right and available
    • Provide the ability to monitor and react to high-speed time-series data
    • Ability to remotely monitor and manage the distributed devices
    • Ability to track usage statistics and bill based on these statistics
    • Proactively monitor units so they could be repaired before the customer lost power
    • Provide insight into customer usage patterns to develop compelling pricing plans
    • Gather, harmonize and use three different sets of data from the various components:
      • Raw telemetry data (voltage, current, temperature)
      • Logs from the box firmware
      • Derived data (power, daily energy usages, state of charge)
    • Lack of staff to manage another solution
    • Keep latency systems at a minimum – their systems were already hosted in AWS and the performance was meeting the needs of the company

    BBOXX is now able to gain insight into its data and apply lessons learned from analyzing past data to develop new and exciting products. The company now uses data stored in a whole new way:

    • Developers ​analyze the data for ways to create new data streams
    • Analysts look for irregularities in usage and write algorithms to detect alerts
    • Business managers look for customer usage patterns
    • Technicians analyze time series voltage and current patterns for remote diagnostics
    • Centralized call center operators reconcile more technical issues for customers by seeing the reason for the outage (hardware failure, over-usage, non-payment)

    In addition, their investors are highly interested in their data collection and analysis as a marker for competitive advantages, reduced delinquencies, growth potential and decreased risk.

    BBOXX uses Amazon Web Services (AWS) to receive store and analyze its steadily increasing portfolio of products. By designing its software architecture with scalability in mind, BBOXX takes advantage of a wide range of AWS’s integrated features including load balancing, auto scaling groups and code deploy to maintain fast, reliable and consistent access both internally and externally.

    Without access to user data, BBOXX would not be able to offer the unique services it does today, which is a fully vertically integrated service, controlling every part of its customer experience.

    About the Author / Mark Herring

    Mark is a zealous marketer who believes that the road to marketing success always leads with the developer. Before InfluxData, Mark was VP of corporate marketing and developer marketing at Hortonworks, SVP of Products at Software AG, VP of Middleware, Java and MySQL Marketing at Sun Microsystems, and VP of Marketing at Forte Software. Earlier in his career, Mark was a developer and technical support engineer for Oracle. Mark holds a B.S. Degree from the University of Witwatersrand, South Africa. Connect with him on LinkedIn and follow him on Twitter.

  • Core Factors Influencing Java Memory Consumption

    Core Factors Influencing Java Memory Consumption

    Java is known for having an insatiable appetite for resources, requiring strict controls to not exceed budget limits. However, the latest JDK updates and other developments have helped to make Java runtime extremely flexible in terms of memory usage. When configured smartly, Java can be cost-effective for different types of applications—cloud-native or legacy, microservice or monoliths. Today, it’s possible to make Java very slim from the start and scale it up gradually without consuming unnecessary resources.

    Here we’ll take a closer look at the factors influencing resource usage inside JVMs, see what tools can help and how processes can be tuned to gain more elasticity and scalability, ultimately reducing TCO.

    Scaling Possibilities: Virtualization vs. Containerization

    Within JVMs there are several scaling options: vertical, horizontal and a combination of both. To maximize results, it is important to start with a vertical scaling configuration that optimizes RAM and CPU usage inside every instance, based on current load levels. As a next step, these settings will be replicated across all instances while scaling horizontally.

    VMs Scaling

    While starting to run a project inside a VM, it is important to pick the right size machine, as too small an instance can lead to performance issues or even downtimes during load spikes. However, over-allocating will result in wasted unused resources during normal load or idle periods that still must be paid for. This can be a tough choice.

    Start with a smaller VM and scale it as the project grows. When just a bit more resources are required, the cloud vendor can offer you to double the size, as this is the most commonly used scaling step (e.g. see AWS offer below).

    During such scaling, the current VM normally is paused to migrate and redeploy the application. This inevitably causes some downtime and requires manual intervention.

    Memory ballooning provides a possible way (although rather complicated) to modify the amount of resources inside VMs on the fly without incurring downtime. However, this process is not fully automated and requires special tools to monitor the memory pressure in the host and guest OS and then activate vertical scaling based on the needs. As a result, memory ballooning doesn’t work well in practice, as the memory sharing should be automatic to present the expected advantages.

    Unfortunately, lack of VM elasticity and efficiency in terms of resource usage often leads to overpaying.

    Containers Scaling

    Containerization presents a new way of application packaging that makes resource consumption more granular and flexible, by automatic resource sharing among containers on the same host using cgroups. Unlike VMs, containers’ boundaries can be easily scaled up and down without the need to pause and reboot running instances.

    There are two types of containers: application and system containers. Both use the same scaling approach but they are intended for different purposes. An application container (such as Docker or rkt) typically is more lightweight, runs a single process and is used mainly for creating new projects, as it is easy to build them from pre-existing Docker image templates.

    A system container (LXD, OpenVZ) behaves like a full OS and can run full-featured init systems. This type of container is preferable for monolithic and legacy applications, as it can reuse the originally created design and important “old school” settings.

    Even system containers are much thinner compared to virtual machines, so scaling up and down takes much less time. And the horizontal scaling process is very granular and smooth, as a container can be easily provisioned from scratch or cloned.

    Garbage Collector Choice

    To maximize the efficiency of the above mentioned vertical scaling inside a Java-based container, it is important to select the appropriate garbage collector (GC) and tune it according to the project needs.

    Let’s review five widely used garbage collector solutions:

    • G1: From JDK 9, this modern shrinking garbage collector is enabled by default. One of its main benefits is the ability to compact free memory space without lengthy pause times and uncommit unused heaps. This GC is considered the best production-ready option for vertical scaling.
    • Parallel: A default GC in JDK8, it is a good option for low pauses but not for memory shrinking. This makes it inappropriate for flexible vertical scaling.
    • Serial, ConcMarkSweep (CMS): Both of these are shrinking garbage collectors with the ability to scale memory usage in JVMs vertically. But in comparison to G1, they require four Full GC cycles to release all unused resources. A new JVM option (-XX:-ShrinkHeapInSteps) in JDK 9 can  speed up memory release by bringing down committed RAM right after the first Full GC cycle.
    • Shenandoah: Shenandoah is a rising star among garbage collectors which promises to be the best solution for JVM vertical scaling. Its main benefit over the others is the ability to shrink in live mode without necessity to call Full GC, which helps eliminate significant performance degradation.

    Let’s compare memory behavior with shrinking G1 and non-shrinking Parallel:

    With Parallel, the unused RAM is not released back to OS. JVM keeps it forever, even disregarding the explicit Full GC calls. So even if your application has low RAM consumption, the unused resources cannot be shared with other processes or other containers as it’s fully allocated to the JVM.

    The modern shrinking G1 garbage collector significantly improves resource utilization compared to the previous example. The reserved RAM increases slowly according to the real usage growth. And all unused resources within the Max Heap limits are not wasted by standing idle, but made available to other containers or processes running in the same host.

    To summarize, Java applications with non-shrinking GC or non-optimal JVM start options hold all allocated RAM. For scaling Java vertically, the garbage collector should provide memory shrinking in runtime. In other words, it has to package all the live objects together, remove garbage objects, uncommit and release unused memory back to the operation system.

    Charging Model of Cloud Providers

    Nowadays, most of the cloud vendors offer a “pay as you go” billing model. This means that it is possible to start with a smaller machine and then add more servers or migrate to a twice-bigger instance as the project grows. But as described above, usually you reserve more than the application actually consumes to avoid the risk of downtime during the load spikes. As a result, many organizations overpay because the account is charged per VM but not based on the consumed resources inside.

    At the same time, there are providers offering  “pay as you use” billing approaches that became possible with the help of containerization, resource granularity and automatic vertical scaling. The payment is based on the resource units inside container. And the required capacity is provided and reclaimed on the fly in accordance with the load at the current moment. As a result, you are charged based on actual consumption and are not required to make complex reconfigurations to scale up or down.

    Taking into consideration all these factors and implementing the right settings can significantly reduce the costs for Java hosting resources, as well as positively influence application performance as a whole. Cloud and container technologies continue eliminating barriers and offering new opportunities for projects with different architectures and budgets.

    About the Author / Ruslan Synytsky

    Ruslan Synytsky is CEO and co-founder of Jelastic. He designed the core technology of the multilingual cloud platform that runs thousands of containers in a wide range of data centers worldwide. Ruslan worked on building highly available clustered solutions, as well as enhancements of automatic vertical scaling and horizontal scaling methods for legacy and microservice applications in the cloud. Ruslan is actively involved in various conferences for developers, hosting providers, integrators and enterprises. Follow him on Twitter.

     

  • Cuba Embraces DevOps, Despite Infrastructure Challenges

    Cuba Embraces DevOps, Despite Infrastructure Challenges

    A few weeks ago I had the pleasure of speaking at the second DevOpsDays event in Cuba alongside some great technologists from across the United States, Europe and Latin America. The conference was held in a beautiful hotel in Varadero overlooking a marina right by the beach. Varadero is approximately two hours by car from Havana.

    The first thing I noticed is that Cuba is full of anachronisms. This became evident as soon as I walked out of Havana Airport and realized that the whole “they have some old cars” thing was real. It was fascinating to see that every single car was pre-1950s, some perfectly maintained with great paint jobs and others in worse condition yet still capable of doing their core job as a mode of transport.

    Talking technology in Cuba was eye-opening, to say the least. Do not expect to have 3G or 4G data on your cellphone. Do not expect to have WiFi in most hotels (you can purchase prepaid internet credit, but the speed will be slower than what you are used to) and definitely do not expect to have WiFi in a private home. These are luxuries.

    But here’s the surprising part: There are companies in Cuba with fully automated CI/CD pipelines achieving 10 to 12 deployments per day and solving real problems, such as the team working under Anesto del Toro at Datys. Cuba even has its very own Docker Captain, who gave a superb demonstration on the value of Docker in front of the DevOpsDays audience.

    Now let me remind you, these guys are not working with stable internet connections and they manage to get the job done on a daily basis.

    Why am I Rambling on About Cuba?

    Engineering is about solving problems. No matter how big or small, it’s about looking at a problem and finding the solution. Now, this is part of Cuban life. If something is broken, they don’t throw it in the trash and buy a new one; they fix it. Their 80-year-old car breaks down two hours outside of town? They get out of the car to fix it and—take my word for this—their friends, family and neighbors will come outside to fix the problem, too. This creates a mindset of solving the problem at hand without fail. This is easily demonstrated when you talk to Cubans about software development: They won’t say they are a Python engineer, a Java engineer or any other choice of language—they are software engineers who understand how development works as a whole. They will use the language required to get the job done to the highest standard.

    Like everywhere else in the world, there were huge differences in levels of DevOps adoption between the various organizations in the country. In contrast to the companies mentioned earlier, there also are organizations that have only just heard of these methodologies or are now considering setting up their first CI pipelines. Like many of us, they are still figuring out how to solve their technical debt and modernize their IT Infrastructure, but the key point is that the stakeholders, C-level executives, junior engineers and everyone else in between want to learn. They are open-minded to the principles of DevOps. Every person in the room at DevOpsDays Cuba was focused and listening to what we had to say. This excited me as a speaker and everyone else in attendance. We could see people who really did want to change and transform the cultures within their technology teams and overall businesses to start adopting these modern and proven practices.

    The journey ahead is a long one. The infrastructure challenges remain in place and there is much to be learned, but it was great to see such positive energy and eagerness to adapt. I want to thank everyone who attended DevOpsDays Cuba for making it such an amazing experience. An even bigger thanks to the organizers Enrique Carbonell, Rudy Gevaert, Yadier Perdemo, Manuel Oliver, Mike Rosado, Manuel Morejon and anyone I’ve missed. The event couldn’t have been better and it was a genuine pleasure to visit Cuba, I hope to return soon and reconnect with as many of you as possible!

    About the Author / Conor Delanbanque

    conordelanbanque

    Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on devopsy.kinsta.cloud.

  • Cloud Services Demand Security Up the DevOps Stack

    Cloud Services Demand Security Up the DevOps Stack

    In the era of soaring use of public cloud by companies, software delivery is moving away from an on-premises install approach to a cloud-based subscription model through software as a service (SaaS).

    Customers expect a lot when it comes to SaaS products and services. Whether they are investing in SaaS-first offerings or shifting workloads to cloud-based providers, companies no longer have upfront costs for hardware and related software or a reliance on costly labor to install, manage and secure it. They expect software that is easy to launch, upgrades that are unobtrusive and feature-rich and limitless scaling to meet their changing business needs.

    When it comes to security, the cloud-based subscription model significantly changes the paradigm of how software security should be treated. Fortunately for many cloud providers, customers trust that a strong foundational security and privacy posture has been built into to the service by design. Preserving that trust requires a healthy tension of shared responsibility between the security teams demanding it and the cloud providers offering it. A new paradigm shift requires a deeper acknowledgement that an emphasis of the security problem “up the stack” to the application layer is needed.

    For security teams, ensuring the protection is built in from the beginning and moves dynamically in lockstep with the workloads requires a much closer partnership with application developers and DevOps teams. This ultimately leads to a richer understanding of the business applications by security teams, creating a more cooperative business-aware and security-minded culture. Getting there will help reduce the tension and improve the overall delivery of secure cloud services regardless of where you sit in the cloud provider/consumer ecosystem and ultimately enables value creation to the business. To get there, a strong partnership must be fostered.

    There are obstacles to moving up the stack. In most companies, the reality is that many security teams are not well-aligned to keep up with this change while the business continues to make cloud-based investments, making the problem worse. Security’s comfort zone seems very much still focused on perimeter defense, but this emphasis isn’t optimally aligned to a cloud-first future. Even when forward-leaning security shops realize a need to change, they often get pushback from app developer teams because security reviews can delay deployment and security tools create “noise” and false positives for app developers. Also, traditional security tools often do not work well in cloud environments.

    Interestingly enough, the No. 1 concern of app developers is preventing data breaches and cyberattacks, a survey of 500 developers and development managers by Veracode found. Less than one-quarter of developers said meeting customer or regulatory compliance is their top concern, while 21 percent said meeting budget and delivery schedules is their top concern, and 19.4 percent said delivering secure code to pass internal audits is a priority. Furthermore, app developers who work with security teams get “major and tangible business and technical benefit,” according to a survey of 150 security and app development pros conducted by Forrester Consulting. Almost all of the collaborators said that working together leads to major or moderate benefit in customer satisfaction.

    Respondents said the more frequently they collaborate, the better the results, “including improved customer satisfaction, business/IT alignment, quality and frequency of releases, and the rate of innovation at their firms.”

    By overcoming barriers to collaboration, app developers and security teams can leverage this knowledge to improve their approach and also come to the table with solutions aligned at moving up the stack. First, they can perform code analysis to uncover vulnerabilities early in the app development process. Second, they can work on stronger runtime protection once the SaaS application is deployed. Code analysis can be used to make runtime protection better, and runtime data can be used to improve code analysis. This creates a continuous improvement loop between the two and both teams can work on code analysis and runtime protection together.

    To achieve this continuous improvement loop, companies must work to break down traditional work silos that exist because of a mismatch in expectations. App developers, measured for speed, need to receive security information accurately, early and with sufficient context to correct problems during software development. Security pros can benefit by installing security tools in production that understand the security needs of their applications, as opposed to tools that require security pros to write rules, tune the tool and then deal with large number of alerts.

    The goal is to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process rather than after deployment, when liability, revenue and reputational risks are the greatest. It is also important to realize that achieving zero defects in source code is a noble but difficult-to-achieve goal. Instead of focusing on extremes, the goal should be to establish a continuous improvement logic in CI/CD (continuous integration/continuous deployment), where bugs are identified, some are fixed and the remainder have fast and accurate runtime protection.

    This shift in thinking and processes will give companies fewer security worries and enable them to more proactively embrace a SaaS-first mentality with higher confidence and trust levels. Companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and improved levels of software security.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • 6 Must-Haves When Using Chat for Incident Management

    6 Must-Haves When Using Chat for Incident Management

    Over the last few years, teams have realized the benefits of sharing and distributing knowledge in chat applications such as Slack. Today, teams are extending the use of these applications beyond collaboration by embracing ChatOps. ChatOps empowers teams by bringing complex day-to-day operational work into shared chat channels. If done correctly, it drastically reduces context switching and increases the speed at which teams can tackle tough challenges.

    Companies are realizing incredible benefits by incorporating ChatOps into their incident management workflows. Chat channels provide hyper-effective means to alert teams of issues, take immediate action and collaborate with clarity and urgency. It is for this reason that companies including OpsGenie, PagerDuty and VictorOps have invested in integrating their incident management applications into chat applications such as Slack, HipChat and Microsoft Teams.

    ChatOps to the Rescue

    Ideally, users of a modern incident management solution need to have access to a multitude of features so that they can address specific challenges directly within the chat tool. During an incident, switching between applications to access and collaborate on the actionable data is a waste of time. Keeping the conversation and action in one place, where team members already are, is the key to a fast and successful incident resolution process. That is why ChatOps has emerged as an alternative to the war room concept.

    To get the most out of the technology and resolve problems more quickly and easily, here are six tips to consider when using ChatOps for incident management:

    1. Post Messages with Clarity

    The basic requirement for integrating any application within chat tools is to simply have messages posted within chat channels. However, there are three additional needs to consider when integrating an incident management tool into chat when increasing efficiency is the goal.

    • The integration must be able to post chat messages regardless where the incident originates and additional information added (monitoring, ticketing, or collaboration tools).
    • Messages need to be customized based on the specifics or severity of the incident. Often the basic message needs to be appended with tags or additional information fields.
    • If possible, include a button in the message that allow responders to take instant, prescriptive actions.

    2.  Control How Information is Shared

    Posting every alert and comment into a shared channel can quickly become overwhelming and is considered bad practice. A strong integration enables the creation of separate channels for specific responders and have direct control over what types of alert and follow-up messages are shown.

    A seamless integration also provides the flexibility to receive only the incident actions that are decidedly relevant. Low-priority issues that don’t require immediate action can be filtered and not sent to the chat stream, ensuring the team stays focused on what really matters.

    3. Accelerate Actions

    ChatOps transforms chat into a vehicle through which users take actions and deploy solutions. This virtually eliminates the need for operations teams to switch between applications when responding to an incident.

    Most integrations enable users to execute incident actions using text commands. This method is valid and often preferred. However, deeper integrations simplify tasks by providing interactive buttons that enable users to begin working on incidents with just a click.

    The value of responding to an alert by clicking a button extends beyond simple alert acknowledgement. Enabling all common responses (i.e. assigning an alert, taking ownership, adding notes, muting incidents, etc.) to be executed in this manner accelerates resolution and unlocks the real power of ChatOps.

    4. Instantly Retrieve Supporting Information

    A challenge of a long chat thread is that critical information can get lost within the communications or additional information may be needed. A user might have to leave the channel to look up important details and related information, such as looking at other open incidents, for example.

    The integration of an incident management system into the chat environment needs to allow users to access supporting information at any time. The ability to query not only additional details about a specific incident but also general information regarding on-call schedules and alert policies is a requirement. By empowering team members to access this data directly within the chat interface, they stay focused and are able to respond in the most efficient manner possible.

    5. Create New Alerts

    A common task when managing an incident is to create manual alerts. Again, requiring people to switch applications to complete this task is a distraction and slows the progress.

    Creating new alerts for a team or service right within the chat channel is a necessity. The incident management system then notifies the person on-call automatically. Having the ability to create an alert directly within chat empowers individuals that may not have direct access to the incident management system to report problems efficiently.

    6. Control Access

    When an incident occurs, it is important that corrective action is taken by only the people who are authorized to respond. Mapping (or linking) the chat users to the users within the incident management system enables this level of control.

    Linking the user profiles between the chat and incident management has additional benefits. As alerts are acknowledged and responded to within the chat environment, the events are recorded within the incident management solution. A clear history describing who took each action is recorded for future reporting and analysis.

    While there are many things to consider when integrating incident management into a chat application, the benefits are clear. Response time, ability to collaborate, and team access to incident details are crucial factors for incident resolution.

    About the Author / Serhat Can

    Serhat Can is a Technical Evangelist for OpsGenie. He has contributed to different parts of OpsGenie as an engineer and now tries to spread the word by coding, writing and talking about DevOps. He is still a proud member of the on-call schedules. Follow him on Twitter and connect with him on LinkedIn.
  • Top 5 Best Practices for DevOps Monitoring

    Top 5 Best Practices for DevOps Monitoring

    Today organizations are required to deliver on higher levels of customer satisfaction for their online services. Many, however, are forced to support these initiatives with an interrupt-driven approach as they react to fix things after they break. However, for a more proactive approach and to manage expected high levels of SLAs, organizations can opt to reduce their amount of unscheduled downtime by implementing a continuous delivery (CD) model to their development efforts.

    What is critical in the CD model is the ability to monitor and manage systems in a structured way, getting early detection of problems so organizations can make changes before the system is impacted. While unexpected failures make interrupt-driven work unavoidable at times, organizations can become more proactive by examining their current approach and toolset against business needs to help create a path to continuous service delivery optimization.

    Effective CD Models Need Effective Monitoring

    As a starting point, organizations need control and visibility into their DevOps environment by collecting and instrumenting everything. Considering the amounts of data, this can be an insurmountable challenge for most organizations. To get started, follow these five best practices to perform DevOps monitoring efficiently and quickly in a measurable and scalable way.

    Step 1: Collect the Data. You can’t manage what you don’t measure! It is important to take inventory of what is being collected today and align with business and executive teams to collaborate on the aim of the services delivered. Analyze the inventory collection of metrics with questions such as: “Why aren’t we collecting this? How does this fit into our goals? Have you ever seen a failure in X? How often should we be measuring this? How long should we keep it for? Is that important?” Teams also should evaluate how they are collecting the information and consider the best architectural approach for collecting their metrics, including whether pull, push or pull collection methods are better. Once goals are understood and the inventory of data is collected, look at what else your organization should consider collecting.

    Step 2: Correlate and Triage. Correlation of data is needed to understand it, but data comes in at different frequencies, in different time frames and from different sources. Work to normalize the data to understand it, perform comparisons against the different incoming metrics and establish baselines for basic service availability. Since organizations aim to go beyond basic service level agreements (SLAs) and offer a high-performing solution, constantly ask what the organization is missing from a data perspective and how it relates to business initiatives. Asking that question from the collection, correlation and triage perspective is critical.

    Step 3: Identify Trends. Organizations need to examine historical data to identify trends and take action before issues arise and customers complain. Establish alerting thresholds by outlining what a normal day looks like from a monitoring performance and customer perspective, and then identifying examples of what makes an abnormal day. This ties in with managing infrastructure inventory and understanding safety thresholds for each of the components that potentially could impact the service offering. It’s critical to communicate these findings with teams and business-line managers to prevent service delivery problems from happening and optimize offerings based on identified trends.

    Step 4: Notify and Act (Automation). In manual mode, a notification is delivered and then the team reacts. But teams are continually pushed to do things faster, and automation can help. To get to that point, organizations must understand where best to add more automation. How do you gather the right telemetry that delivers consistent answers that the machine can operate rules against, and do you leverage an automated process or notify a person? The desire to improve to a faster process requires a shift from manual to automated practices.

    Step 5: Predict (What-if Analysis). If you don’t take the time to go through the first four steps in a methodical way, it’s very difficult to reach this final step without always remaining in a manual mode. To balance costs and availability, it’s critical to discuss with the executive team how to predict customer service consumption (revenue) against the amount your services are going to cost the business.

    For example, developing a service that can alert customers of a potential service disruption due to disk space can be accomplished only by clearly setting business goals, then using the right metrics and events platform leveraging a time series database. In this case, the business goal is to ensure no service disruption due to failures such as low disk space; the metric monitoring is for disk space for each customer instance with the appropriate threshold alert set off by an automated trigger; and the action is an email to the customer letting them know of the situation and what action they can take (reduce load or upgrade for more disk space). In this example, it is important to marry business logic with the monitoring practice to make service a successful experience for customers. Furthermore, this approach will help teams to not only predict user experience but also help to predict OpEx and CapEx better into the future.

    That’s the benefit of the ability to predict with the right monitoring approach—to make informed business decisions based on results. Customers appreciate that, and proactive support is much better than being reactive.

    Emerging trends such as microservices, containerization, elastic storage, software defined networking and hybrid clouds are pushing the boundaries of DevOps monitoring. The right monitoring plan can identify and resolve problems before they affect critical business processes and enables customers to plan for upgrades before outdated systems begin to cause failures and outages for users.

    About the Author / Mark Herring

    Mark Herring is CMO at InfluxData. He is a well-rounded silicon-valley executive with proven experience in taking complex technology and making it understandable to the broader audience. His deep developer roots are never far from his mind as he looks at trends and asks the tough questions on whether the technology is here to stay or just another fad. Currently Mark is Chief Marketing Officer at InfluxData. Follow him on Twitter and connect with him on LinkedIn.

  • Kubernetes is the Universal Cloud Infrastructure

    Kubernetes is the Universal Cloud Infrastructure

    Before I started Rancher Labs, I created a company called Cloud.com where we developed Apache CloudStack. We were inspired by the early success of Amazon Web Services (AWS) and wanted to make it possible for everyone to stand up AWS-like cloud infrastructure for themselves.

    While CloudStack was successful in powering a number of public and private clouds, it failed to achieve mass adoption. Instead, cloud infrastructure today is increasingly concentrated in a small number of very large public cloud providers such as AWS and Microsoft Azure. There are a few reasons for this:

    1. It takes a lot of capital investment and operational expertise to operate cloud infrastructure. Only large players can benefit from economy of scale.
    2. There is no consistency among different cloud infrastructure providers. Even if a smaller provider can beat an established player on price, it becomes increasingly difficult for customers to migrate workloads from one cloud to another.
    3. The scope of cloud infrastructure services is forever expanding. It is no longer sufficient to offer basic compute, storage and networking services. Leading providers such as AWS offer an ever-growing number of services for data processing, analytics and artificial intelligence.

    Despite the downside of cloud lock-in, organizations are facing increasingly fewer choices in cloud infrastructure as they adopt cloud computing.

    Enter Containers and Kubernetes

    We started Rancher Labs because we saw that containers can potentially change the game in cloud computing. Docker is a universal application packaging standard that makes applications portable. Kubernetes adds cluster management to Docker. Many people think the power of Kubernetes lies in its ability to manage applications and microservices. We completely agree. We believe, however, that Kubernetes also brings significant benefit by hiding the differences between cloud infrastructure providers. Kubernetes comes with a rich ecosystem of plugins for storage, networking and load balancing. As a result, it does not matter where you have deployed Kubernetes. As long as the drivers are configured correctly, users get a consistent view of cloud infrastructure regardless what cloud provider they use.

    In addition to offering consistent storage, networking and load balancing, Kubernetes also brings with it a rich ecosystem of higher-level services for developers. The Cloud Native Computing Ecosystem includes all major providers of system- and platform-level software. Kubernetes has become the center of gravity of innovation in cloud computing. New capabilities are made available at a faster pace than anywhere else.

    In the early days, it was quite challenging to setup and run Kubernetes. Companies such as Rancher created Kubernetes distributions that make it easy for DevOps and IT teams to deploy and operate Kubernetes clusters. Today, many cloud providers offer Kubernetes as a service. At Rancher, we are now more focused on managing Kubernetes clusters. We expect most, if not all, major cloud providers to support Kubernetes in the future. When that happens, Kubernetes will be the universal cloud infrastructure.

    If you use cloud computing, there is no reason not to use Kubernetes. You get the most complete ecosystem support and the same consistent experience no matter where you go. Cloud lock-in will be a thing of the past.

    About the Author / Sheng Liang

    Sheng is a co-founder and CEO of Rancher Labs. Prior to starting Rancher, Sheng was CTO of the Cloud Platforms group at Citrix Systems after their acquisition of Cloud.com, where he was co-founder and CEO. Sheng has more than 15 years of experience building innovative technology. He was a co-founder at Teros, which was acquired by Citrix in 2005 and led large engineering teams at SEVEN Networks, and Openwave Systems. Sheng started his career as a Staff Engineer in Java Software at Sun Microsystems, where he designed the Java Native Interface (JNI) and led the Java Virtual Machine (JVM) development for the Java 2 platform. Sheng has a B.S. from the University of Science and Technology of China and a Ph.D. from Yale University. Follow him on Twitter.

  • Building a Services and IoT Platform with DevOps, Part 4

    Building a Services and IoT Platform with DevOps, Part 4

    IoT platforms and their solution development have crossed different maturity levels. At first, devices were primitive, isolated and working with limited functions before slowly evolving to communicate and connect with other devices using lightweight communication protocols, and then stepping into advanced level with remote management of devices, harvesting the data from devices and smart decisioning and analytics. Beyond that, IoT has moved to optimized levels of using multiple technology options and adopting cloud and DevOps disciplines to build intelligent IoT solutions.

    This article focuses on giving insights on choice for IoT platforms and factors influencing build or buy options for IoT solutions, different hosting options, factors on IoT development in the cloud and more.

    IoT Platforms: Build, Buy or Both?

    The dilemma of whether to build an IoT system from scratch or buy an off-the-shelf platform still continues. Below are some of the key factors to consider before making the critical decision.

    1. Price: If you plan to build an IoT platform, the infrastructure setup and operation costs can be high. And, as you plan to scale, there will be additional infrastructure cost in setting up additional data centers in that region. If you buy an IoT platform, prebuilt infrastructure is available across global data centers to scale out on a per-usage basis. Plus, you get the the benefit of buying devices from a certified partner ecosystem with discounted device prices. You can buy a few devices from cloud vendors or other device manufacturers, and use mix of devices, mix of cloud/multi-clouds or on-premises, using mix of platform as a service (PaaS)/infrastructure as a service (IaaS) at competitive prices.
    2. Time to Market: A house-built IoT systems will typically take about six to 12 months to complete, including infrastructure setup, device development and software development and testing. Depending on the complexity of the business case, the release cycle may take even more time to get to production, especially with ongoing device technology updates, lack of protocol standards and new business demands.
      Under the buy option, you can buy preconfigured end-to-end solutions available for common IoT use cases such as remote monitoring, predictive maintenance and connected factory, and these solutions can be customized based on need. You can even try to build only few components of IoT solution which may not be available from the vendor, such as the devices/edge, build a field gateway and use preconfigured solutions for data ingestion and data processing, data analytics and data storage components. There are starter kits available to quickly prototype, evaluate and deploy, eliminating spending more cost and effort, before hitting to the ground.
    3. Skillset/Expertise: Building an IoT platform requires a skilled team with expert knowledge of software and hardware and development, which costs more. Currently there is lack of skilled IoT experts with a mix of software and hardware knowledge in traditional industrial-based enterprises.
      When buying a IoT solution from vendors, the solutions are prebuilt and guided by standards and best practices. The platforms are built by experts who are proven with cloud infrastructure, based on their experience working with large customer base and customer support—necessary for IoT platform development.
    4. Scalability: When you plan to scale your business, you need to scale your infrastructure as well. With millions of devices connecting to your infrastructure to send and receive data and firmware updates, monitor the devices, support multiple range of network providers and store large volumes of data being collected and processed, you need a scalable infrastructure on-premises or in the cloud to meet those demands. Setting up a scalable infrastructure on your own requires skilled labor, effort and cost.
      Real-time streaming and data processing capability is available for large volumes of data workload, enabling scaling of individual components of IoT solution, as well scaling as scale units (group of components for data ingestion, data processing and data storage). Choices of different cloud vendors give you options to scale based on demand, horizontally or vertically, adding/removing devices with portability options and providing on-demand simulated test environments with the flexibility to choose multiple clouds or a mix of PaaS/IaaS options from different clouds or hybrid infrastructure.
    5. Security: For in-house IoT development, teams should be aware of various security attacks and develop systems with current security strategies and technologies to both protect data and devices and maintain data privacy. A large infrastructure is needed to support the sandboxed hosting of data in separate geographic regions for secure data storage, device security and user security.
      IoT platform vendors provide security standards. For example, Microsoft provides SDL (Security Development Lifecycle), which enables developers to follow the standards during device development and ensures development happens with security built at all parts of system. These platform providers have prebuilt infrastructure for secure data storage, cloud security, user security, application security and device security, and has separate security teams to protect the data at all levels.
    6. Analysis & Visualization: It’s estimated that 90 percent of the large volumes of data collected from millions of devices remains unused in most enterprises. To tap the data for valuable business metrics, data analysis/algorithms should be updated as industry and device requirements change and extensions are needed to integrate data with data analysis tools to churn the data. There are open-source and proprietary tools available for data mining and data analytics and custom dashboards must be built to monitor the telemetry, setup rules and actions.
      Preconfigured solutions and most IoT platform providers have out-of-box data analysis tools integrated and rules can be defined to analyze data with customizable dashboards, enabling you to focus more on business outcomes and how to churn/mine data, rather than focusing on building algorithms/tools/dashboards from the scratch.

    Factors Driving Cloud-based IoT Development

    Considering the various factors, a hybrid option with mix of buy and build for IoT platform components is better compared to building the platform from scratch, as you get out-of-the-box features from the off-the-shelf platforms that are customizable and extensible to business needs.

    The following are some of the factors driving more and more IoT development in cloud (single/multi-cloud/hybrid), making IoT grow exponentially:

    1. Increasing number of devices – billions/trillions of devices interconnected
    2. Need for remote processing power and high compute
    3. Need for hyperscale systems for processing hot/cold/warm/fast data pipeline with low latency
    4. Need a platform that can quickly evaluate, prototype and deploy IoT applications
    5. Need a platform that provides security by design across devices, gateways, networks, data processing, users and applications
    6. Usage of advanced analytics and monitoring solutions available in cloud
    7. Leverage interdevice communications, interservice communications
    8. Utilize preconfigured IoT solutions for most of the popular use cases such as remote monitoring, predictive maintenance, with proven practices/patterns.
    9. High data storage, highly scalable with minimum cost to deploy
    10. QoS features in cloud—security, performance, usability, backup, etc.
    11. Cloud gateway providers have support for various devices and provides extensibility
    12. Cost of devices, cost to deploy and internet usage has dropped
    13. Out-of-box support and availability of big data and machine learning techniques in the cloud with mobile data visualization
    14. Ease of integration with DevOps tools in cloud, end-to-end testing with simulated devices as containerized environments in cloud

    Expanded internet connectivity, reduced cost of devices, increased spread adoption of remote devices such as smartphones, usage of big data, machine learning techniques and cloud adoption, competitive pricing models and more are the key drivers for IoT’s growth in cloud.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in IOT, Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.