devopsy.kinsta.cloud

Tag: containerization

  • DevOps at Scale: Winning Strategy for Modern Enterprises

    DevOps at Scale: Winning Strategy for Modern Enterprises

    DevOps is a word that has generated massive interest over the last few years among the software-powered organizations and developers, yet many people don’t fully understand what it actually means. One thing is for sure, as cool as it sounds, DevOps is not some kind of top-secret developer army group, job profile or even a tool. It is a wonderful ideology that any firm can help itself to unite their tech crew and take the company to newer heights.

    As different departments grow, communication becomes difficult between the teams, mainly development and operations. Since communication is the key to avoid unproductive siloing, the DevOps movement started as a cultural phenomenon in order to bridge this gap between dev and ops. So firms started embracing DevOps principles to get everyone on the same page and create a sense of shared responsibility, and moving forward, firms believe that was the recipe for success.

    Where Does DevOps Come into Play?

    Automation is one of the things DevOps is most known for. Automation reduces the amount of work, and smaller batches of work are easier to understand, commit to, test, review and know when they are done. These smaller batch sizes also contain less variance and risk, making them easier to deploy and, if something goes wrong, to troubleshoot and recover from.

    With DevOps best practices like CI/CD, it is easy to understand which code has created bugs and make possible corrections wherever necessary. 

    Just like lean development, through automation and agile practice, firms can get feature development very close to single-piece flow, and this provides value to customers quickly and continuously by delivering features as quickly as possible. 

    More traditionally, DevOps is referred to as a means to break down the walls of confusion and chaos between the dev and ops teams and smoothen the flow of communication. In the DevOps model, development teams develop new features, and operations teams keep the system more reliable for customers, stable and running smoothly.

    Today, we will see some important elements that help firms to embrace DevOps with ease.

    Start a Cultural Shift, a DevOps Initiative

    This should flow from top to bottom, company management leaders should start the discipline of embracing DevOps. Usually, it is the CIO who should move the needle and make things start from scratch. A DevOps mindset is very crucial at this point to make sure the teams are all prepared for a change in the culture.

    Gartner predicted that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. One of the main reasons why DevOps efforts fail is that most of the organizational leaders don’t understand Agile and DevOps. Leadership makes a huge impact on the organizational culture and its way of doing business, hence engineering leaders need to understand why this change is necessary and start a culture of collaboration, culture of experimentation and learning, and eliminate the blame game. 

    Train Your People

    Training is one essential aspect for team leads and the people involved under them so they understand what DevOps is, the fundamentals, and why it is important for the organization to embrace it. Training enriches knowledge, collaboration and communication processes between the people working in development and operations teams. 

    It helps them to get together and get their hands on, test the new technology practices and tools introduced. There are many group courses, boot camps and DevOps experts that can help people get trained in DevOps. It is the firm’s responsibility to set proper expectations and choose the right candidates to train their people. 

    Build a DevOps Plan with a Strategy

    All those engineering best practices that enhance automation, team collaboration, seamless integration and testing that facilitate new ways of software development with ease are key to a DevOps strategy. Firms have to set a common goal, track changes and align teams in a shared environment making them aware of each other’s responsibilities and duties. Implementing Infrastructure as Code (IaC), test automation, integration, deployment and release processes should be a part of it.

    Set Policies and Processes

    The policy is an integral part of any software powered organization. With security being the priority, this has become a supreme topic in the DevOps world. For every company that has adopted DevOps, the policy is critical. As we all know, policy-driven development is a fundamental concept that fits really well into the DevOps model. This model ensures that information security, ops, development practices, language standards, SRE, sysops administration and development, are all aligned with common goals.

    Containerize Applications

    Containers are well equipped with the IaC approach and are used in DevOps to instantly deploy applications across various environments. Docker provides the most popular container technology toolset. Docker image management technologies, such as Amazon ECR, have made it easy for developers to perform IT operations, collaborate with each other, share software and enhance overall software delivery productivity.

    Containerizing legacy applications will reduce the burden of handling the ever-growing overhead costs and it also increases developer productivity. Container deployment can be an effective solution as containers typically start in seconds. The container image holds all the dependencies, meaning there is no need to add environment-specific configurations. The same image is now portable across multiple systems and environments. The main idea is to make applications able to run anywhere, on any machine and at any given time. 

    Make Use of Microservices Architecture

    Decouple the legacy and monolithic application that involves thousands of lines of code into numerous small elements called microservices. With the idea of microservices, a company continues to innovate and stay agile as the products or the platform gets larger. With this approach, engineering teams focus on developing business capabilities and important features autonomously.

    Instead of having to orchestrate a large release after writing hundreds of lines of code, waiting for the perfect time to offer new features, a new business functionality can be added by just adding a new service. Eventually, firms end up creating microservices that can be easily and independently deployed, scaled and managed without having to worry about other parts of the application.

    Determine the Toolchain

    When companies initially start embracing DevOps they feel proud, but they find it hard once they really start working toward it practically. The simple logic for this is: DevOps is fragmented. 

    For many years, firms have tried to embrace DevOps and have found themselves making various mistakes by their custom scripts and logic. From source control to CI, to artifacts management to CD, as soon as one task is completed, the next step should proceed without any lag, and that is how the firms achieve their DevOps automation. But in practice, this doesn’t happen.

    There are many handovers that take place manually—that is not called DevOps. Custom scripts and practices might work temporarily for a startup but when the company grows, taking different tools and writing code to make them talk to each other becomes a complex task. For this reason, recently, JFrog has launched a unified DevOps platform for companies struggling with doing DevOps at scale. 

    Companies around the globe are in a race to innovate and release software and valuable features to their customers as early as possible to stay ahead of the competition. You need a platform to deliver software updates fearlessly from code to the edge. It would help if you had an end to end universal DevOps solution, like JFrog platform, to manage your entire DevOps pipeline. A highly scalable enterprise platform unifies the management of all services in a single pane of glass. The JFrog platform is Kubernetes ready to manage your Docker images and Helm repositories for your Kubernetes deployments. It has everything you need to do DevOps, from artifactory repository management to distribution.

    Continuously Monitor and Share Feedback

    Once we deploy the application in production and make it available for the end-users, the next step is continuous monitoring. This alerts the team if there are any misconfigurations or worse situations of an outage or of any application issues. You can monitor infrastructure health, or if would like to see and analyze logs over weeks and months, you should be able to do so.

    This step provides critical feedback, essential for the team to understand and work on the aspects of the application that require additional work and resources. Continuous monitoring enables you to find issues (if any) before any customer finds them. Having no visibility is just like getting your arms tied behind your back, you can’t really see what is going on. 

    Conclusion

    Other than easy collaboration, improved communication, an increase in productivity and effective feedback loops, the one benefit DevOps will bring is delivering software at speed without compromising on quality. DevOps is an ongoing effort and helps people in the organization fail early and learn early from their mistakes, and it builds confidence. DevOps implementation can look too overwhelming at times, but a prepared approach with a well-thought strategy can take your firm from zero to hero. Given that the teams have patience, persistence and ever-learning attitude, it is possible to scale DevOps to new heights. 

    — Pavan Belagatti

  • Mphasis Acquires Stelligent, the DevOps Automation Services Specialist in the Amazon Web Services (AWS) Ecosystem

    • Mphasis Stelligent boosts Mphasis’ end-to-end capabilities in public cloud with a focus on DevOps and Containerization; further augmenting its managed services capabilities
    • Mphasis Stelligent combines best-in-class DevOps and DevSecOps solutions on Amazon Web Services (AWS) and delivery at scale with customer-centric digital transformation and hyper-personalization to enterprise clients

     New York / Bangalore, November 8, 2018

    Mphasis (BSE: 526299; NSE: MPHASIS), an Information Technology (IT) solutions provider specializing in cloud and cognitive services announced today its acquisition of Stelligent Systems LLC, a technology services company specializing in DevOps automation on Amazon Web Services (AWS). Headquartered in Reston, VA, Stelligent provides DevOps and DevSecOps solutions on AWS. The company is a Premier Consulting Partner on AWS Partner Network (APN) and holds both AWS DevOps and Financial Services expertise in deploying their customers’ applications on AWS with greater speed, agility, and security. The acquisition is an all-cash deal valued at USD 25 million.

    Since inception in 2007, Stelligent’s driving mission is to ‘help their customers gain the ability to continuously deploy their software when they want to and with confidence’. The company has been providing leading enterprises, including Fortune 500 companies, with continuous integration and delivery solutions on AWS and has built its brand as a pioneer and visionary within the AWS ecosystem.

    “The advent of public cloud infrastructure and SaaS software has elevated the importance of rapid automation in product development and product engineering for enterprises moving to the cloud. Together with Stelligent and its community heroes in the AWS ecosystem, we believe we are uniquely positioned to take advantage of this market opportunity. This allows us to join forces with an equally technically-deep company, bringing innovative, in-depth cloud solutions to enterprises in all Mphasis client segments,” said Nitin Rakesh, CEO and Executive Director, Mphasis.

    “Stelligent is very excited to further its DevOps capability across a broader range of clients and become central to Mphasis’ AWS go-to-market strategy. Our engineers will greatly benefit from being part of a larger, complementary tech-centric community; as well as serve enterprises in end-to-end AWS DevOps, DevSecOps and additional AWS cloud services,” said Bill Santos, CEO, Stelligent. 

    Stelligent’s team of over 50 engineers hold over 100 certifications and significant experience and expertise in DevOps Automation as well as one of a select few consulting partners with two AWS Heroes – an AWS Community Hero and an AWS Hero for Containerization.

    Safe Harbor: 

    Certain statements in this release concerning our future growth prospects are forward-looking statements, which involve a number of risks, and uncertainties that could cause actual results to differ materially from those in such forward-looking statements. The risks and uncertainties relating to these statements include, but are not limited to, risks and uncertainties regarding fluctuations in our earnings, revenue and profits, our ability to generate and manage growth, intense competition in IT services, wage increases in India, our ability to attract and retain highly skilled professionals, our ability to manage our international operations, reduced demand for technology in our key focus areas, withdrawal of fiscal governmental incentives, political instability, war, legal restrictions on raising capital or acquiring companies, and general economic conditions affecting our business and industry. We may, from time to time, make additional written and oral forward-looking statements. We do not undertake to update any forward-looking statement that may be made from time to time by us or on our behalf.

    About Mphasis 

    Mphasis (BSE: 526299; NSE: MPHASIS) applies next-generation technology to help enterprises transform businesses globally. Customer centricity is foundational to Mphasis and is reflected in the Mphasis’ Front2Back™ Transformation approach. Front2Back™ uses the exponential power of cloud and cognitive to provide hyper-personalized digital experience to clients and their end customers. Mphasis’ Service Transformation approach helps ‘shrink the core’ through the application of digital technologies across legacy environments within an enterprise, enabling businesses to stay ahead in a changing world. Mphasis’ core reference architectures and tools, speed and innovation with domain expertise and specialization are key to building strong relationships with marquee clients. Click here to know more.

    About Stelligent 

    Stelligent provides DevOps automation professional services on AWS, enabling engineering teams to focus on creating software users love. Our goal is to work closely with customers to develop fundamentally secure infrastructure automation code, deployment pipelines, and feedback mechanisms for faster, more consistent software and infrastructure deployments. For more information, please visit: www.Stelligent.com.

  • When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When people in the DevOps world hear the word “containers,” most of the time they imagine the lightweight, standalone, executable Docker binaries that have become commonplace in today’s cloud infrastructure. It might come as a surprise, however, that the world of mainframe computing not only supports traditional Docker containers, but also expands the concepts of isolation and safety into another type of containerization technology called IBM Secure Service Container. For companies running Linux on an IBM Z, Secure Service Container brings a new dimension of security to mainframe computing.

    Mainframe computing already offers a lot of power that is difficult to match in a commodity x86 environment. For example, the IBM z14 mainframe can store up to 32TB of memory. It has a 10-core z14 CPU that can run at speeds up to 5.2 GHz, which is considerably faster than the ~4 GHz of a 4-core Intel i9 processor. With this power, the mainframe can perform 30 billion RESTful transactions a day running Node.js and MongoDB in standard Docker containers. Mix in the versatility and code reuse that running Linux on a mainframe provides, and you get a level of computing power that’s hard to ignore.

    In terms of application development, putting Linux on a mainframe allows applications written in popular languages such as Java, Python or Node.JS to run on an IBM Z system just as they would in a data center full of x86 machines. And the total cost of ownership of a mainframe can be surprisingly  competitive when compared to a commodity system.

    Despite these  benefits, Linux on a mainframe faces many of the same security challenges that other platforms have, both in terms of hardware and software intrusion. The difference is that IBM Z is more secure out of the box and offers a number of additional technologies to address these challenges—100 percent application data encryption, isolated workloads for multi-tenant environments, full lifecycle encryption key management with encrypted keys and tamper-responding cryptographic hardware. But many times, safety boils down the security acumen of the system administrator and the overall security discipline instilled within an organization. Some organizations have excellent security practices. Others are challenged. Regardless of the degree of competency, it is difficult  to lock up a box in a bulletproof manner. This is where Secure Service Container technology comes in to play.

    Working with Secure Service Container

    Secure Service Container combines hardware virtualization, applications and data into a secure, encrypted “container” (partition). The encryption keys are protected in the Secure Service Container partition. Should a key become compromised or attempts are made to tamper with the keys, the Secure Service Container will invalidate the key and the encrypted contents will become inaccessible.

    Once the Secure Service Container is deployed (via the physically secure hardware and firmware), everything inside it is fully encrypted. The boot sector becomes tamper-proof and memory access is disabled. Also, access to the system via SSH is also removed. As a result, hardware and operating system SysAdmins have no direct way to tamper with the environment beyond RESTful interfaces for communication and management.

    Using SSH to administer a system leaves a lot of opportunity for catastrophe: While Linux allows you to limit access to commands according to group and user permissions, just one unsecured executable mistakenly installed in the environment can cause a mishap.

    On the other hand, the only way to access an Secure Service Container-enabled environment is via a set of APIs. Each piece of administrative functionality associated with the Secure Service Container API is represented as an endpoint with an access method. Thus, the advantage of secure access via an API is that work is done over a common interface on a task-by-task basis. A distinct security policy can be applied to each endpoint and associated access method. This is a very fine-grained security model.

    Using an “API only” approach for access means that for all intents and purposes, the system is completely locked down. Even root users and SysAdmins are denied access that is not granted according to the security policy on the given endpoint. Thus, “Snowden-type” attacks are prevented.

    The HSM—the physical device that encrypts and protects keys—is certified to FIPS 140-2 Level 4, which is the highest security standard defined in the Federal Information Processing Standard. Also, the individual Secure Service Containers are isolated to EAL5 and higher levels, giving you near-air gap isolation between containers to ensure that side-channel attacks won’t work. This is industrial-strength security that is designed to meet the needs of extremely security sensitive environments such as banks, power grids, the Atomic Energy Commission and the CIA. Secure Service Container is serious technology for serious enterprises. However, Secure Service Container can benefit any company that wants to dive  into the world of mainframe computing, the costs of which can be surprisingly affordable.

    A New Way of Thinking

    When most people think about mainframe computing, they think of large companies with big budgets to spend on high-priced  hardware. While this might have been the case in the past, today mainframe technology is well within the grasp of smaller companies. Today’s mainframes can be as much as 92 percent lower for total cost of information compared to their x86 competitors. And when you take into account the added agility, scale and security, setting up an on-premises cloud installation using an IBM mainframe as opposed to a rack of x86 machines seems very reasonable.

    The mainframe offers significant benefits besides cost, particularly when Secure Service Container technology gets added to the mix. To start with, running Linux on a mainframe creates a common playing field in terms of application development. Most Linux-based application code can run on a mainframe as well as on a PC. This means that a single Java developer can leverage his or her expertise to write for a variety of environments—PC, Android or mainframe.

    Security Risks by the Numbers

    ●      Cybercrime damages will cost the world $6 trillion by 2021

    ●      The average cost of a data breach in 2017 was $3.6M

    ●      60% of the victims of victims of cyber attacks run the risk of being put out of business

    ●      Every 14 seconds a business will fall victim to a ransomware attack

    ●      Only ⅓ of enterprises are security testing containers intended for production

    The mainframe also offers very large storage, incredibly high computing capability and a unified environment. Both applications and database can live within the same box, diminishing network latency and increasing overall processing speed.

    Secure Service Container technology make security both robust and easier to manage. The “API only” access approach to system administration makes support a secure, standardized undertaking. From a DevOps perspective, the standardization provided by the “API only” approach is easy to automate and you avoid having to accommodate the peculiarities that go with system administration at a lower level of operation.

    Finally, as mentioned above, Linux on IBM Z supports Docker. Integrating mainframe resources with the Docker ecosystem enables high-powered, high-volume, ephemeral computing within a single machine installation. A single Linux on IBM Z installation can support up to 1 million Docker containers. And, because these containers reside on the same machine, they can take advantage of co-location with other mainframe workloads and minimize the impacts of external network latency. As anybody who has worked with a distributed architecture can tell you, a containerized microservice is only as good as its availability. Putting all containers on a single computer reduces the risk of interservice communication failure significantly. This is a very big deal—especially considering the 99.999 percent uptime of IBM Z.

    Putting It All Together

    Containers are fast becoming the foundation of modern cloud computing. There’s more to  containerization however, than creating instances of Docker images. The concepts behind containerization have broad application well beyond commodity based computing. Secure Service Container combines the best practices intrinsic to both hardware and software security to create a Linux-based environment that makes mainframe technology a first-class player in the world of modern cloud computing.

    Given the decreasing costs and increasing benefits of technologies such as IBM Z and Secure Service Containers, mainframe computing can become a significant asset to any company. All that’s really required is taking the time to understand the power available and explore the possibilities at hand.

    Learning More

    You can learn about about Linux on IBM and Secure Service Container at the following resources:

    — Bob Reselman

  • DevOps in 2017: From Building to Executing

    DevOps in 2017: From Building to Executing

    In 2016, DevOps grew in popularity and use, new tools were introduced and enterprises across industries realized the influence and benefits derived from agile development. But there are even more developments to look forward to as enterprises engage DevOps teams further.

    Scaling-out solutions, providing a baseline for a new cultural approach to problems and continuous improvement will continue to be priorities. But there are a few items that we’ll likely see come to the forefront in the new year. In fact, 2017 should be an even more exciting year for DevOps.

    Here are my top four predictions for what we can expect this year:

    The next phase of DevOps will focus on security

    Security was a perennial news event throughout 2016, and we can expect the same in 2017. However, DevOps teams likely will be challenged to build good security practices into code as a part of application development, rather than refining security post-facto. This will lead to DevOps, QA and operations bringing security teams deeper into the DevOps environment, if not outright incorporating them as a part of the team.

    The foundations for this development were put in place in early 2016 as the DevSecOps model gained traction in cybersecurity circles throughout the year. In 2017, we’ll see DevSecOps teams build on these foundations. After all, every company is at risk for a data breach.

    Containerization will go mainstream

    The convenience of containerization makes it one of the most desirable technologies for DevOps teams, and next year we’ll see it gain even greater use. It’s easy to understand why: Containerization solutions, such as Docker, grant teams the ability to provide a consistent environment from development to production. We may even see containerization move to non-production environments over the course of 2017 due to its portability across multicloud platforms. And that portability is critical not just for production purposes but for security as well.

    DevOps will extend into pay-as-you-go

    DevOps will, almost by necessity, develop an on-demand model in 2017. Companies are realizing the stark demand for DevOps skills and they will be meted out according to internal needs and external demands.

    In particular, we’ll likely see a lot of opportunity for DevOps in cloud implementation, since enterprises leverage solutions across cloud providers. With cloud provider “lock-in” still a real concern for many enterprises, any provider capable of operating cross-cloud development—thereby allowing customers to switch to a low-cost cloud provider—will be in high demand. This is good news for customers, as it allows them to finally benefit from the elastic nature of cloud pricing models.

    DevOps will become pervasive across the enterprise

    Finally, enterprises will use DevOps across the enterprise. Thus far, large enterprises have been experimenting with DevOps in discreet projects, but they have started to plan for employing DevOps principles at enterprise-level, and we will see this roll out next year.

    Watching the Shift

    Thus far, DevOps has been focused on adopting and orchestrating technology and tools to build automation pipelines. But moving ahead, we’ll witness DevOps change its focus from building to executing. With this industry development and the shift within DevOps to security and containerization at an enterprise level, we’ll begin the true potential of DevOps.

    About the Author / Tan Moorthy

    Tan Moorthy is Head of Global Services for Application Development and Management at Infosys, a next-generation IT services provider. Connect with him on LinkedIn.

     

  • Infrastructure Management in the Age of DevOps

    Infrastructure Management in the Age of DevOps

    DevOps has emerged as the de facto cure-all for all that’s wrong with enterprise IT, breaking down silos and replacing them with agile and transparent relationships between developers and operations and seamless, fast workflows that drive greater efficiencies across IT. But legacy IT systems still need tending, even in a DevOps world. They must be secured and scaled, load-balanced, configured, backed up and monitored for compliance, without interruption to the enterprise—all considered infrastructure management tasks.

    And that’s a problem, because these tasks often are handled manually using pre-DevOps processes, which breaks down the very promise of agility, speed and rapid service delivery that DevOps delivers.

    Oleg Chunikhin, chief architect with EastBanc Technologies, emphatically agrees. “If an organization goes down the DevOps path, invariably old habits get carried over into the new world over. For example, if there’s a glitch with release management or a broken disaster recovery process, these problems are dealt with as they occur, or not at all, until they reach a point of critical mass.”

    Chunikhin and I sat down to further discuss the issues and infrastructure management options available to any organization embarking on a DevOps strategy. Here’s our conversation.

    Wolf Ruzicka: Why do infrastructure management tasks pose such a risk to DevOps success?

    Chunikhin: One of the key problems is that there is a limited set of clear leaders in the DevOps tools and architectures market. There are tools for one thing (e.g. containerization) and tools for another (software configuration), and so on. But the market lacks a repeatable, standardized, off-the-shelf solution for infrastructure-level problems.

    Instead, organizations could look to re-architect what’s already there. But this can turn out to be a risky, painful and expensive business. So, you’re left with few options.

    As a result, making the move to DevOps becomes a challenging and risky endeavor for any CIO. If they take that risk, they end up attached at the hip to the time-consuming and manual processes that they already know—which go against the very promise of DevOps.

    Ruzicka: What are the key DevOps infrastructure management considerations that IT needs to bear in mind?

    Chunikhin: First and foremost, don’t delay. CIOs must recognize the problem of infrastructure management in a DevOps environment, before it’s too late. As they explore DevOps, forward-thinking organizations need to consider how its concepts and challenges can fit their organization:

    • How can manual processes be eliminated?
    • How can you strike a balance between the demands of the business and the need to operate in a compliant, stable and secure environment?

    By addressing these challenges early on, you’ll ensure that each of these co-interdependencies is manageable. Before processes break down and critical systems are out of sync.

    Ruzicka: Don’t emerging trends like cluster management and containerization address this very problem?

    Chunikhin: Yes and no. Cluster management is an important part of any DevOps architecture. By abstracting out everyday management tasks, such as backups, and using orchestration to introduce efficiencies into complex environments, it’s a useful tool. But, cluster management software is notoriously difficult to set up for production use. While it can help developers manage many aspects of complex production environments, it isn’t a complete solution in and of itself.

    Containerization helps with multitude of DevOps-related problems (software configuration, package conflict resolution, dependency management, etc.), but containerization alone is also not a complete solution.

    Cluster management software combined with containerization, a.k.a container orchestration technologies, on the other hand, is the most recent and very promising development in the area of DevOps technologies. It promises out-of-the-box SaaS-like capabilities for fast service delivery, production quality, reliability, security, disaster recovery and so on—with less expertise needed for overarching DevOps workflows. This relieves much of the pressure on DevOps teams by eliminating the need for custom software development, lowering maintenance costs and introducing automation.

    Although each solution has its benefits, neither is a panacea for DevOps infrastructure management. Today’s cluster management software, containerization and container orchestration systems differ wildly in their capabilities and are often incompatible with older/legacy software. The task of integrating each with existing back-end systems and ensuring compatibility with existing environments is a perpetual challenge in hybrid deployments, where everything must work together for seamless DevOps. In our experience, each presents unique issues that prevent them from becoming standard on any client project.

    Ruzicka: Without a standard “one-size-fits-all” offering, how do organizations address their DevOps infrastructure management challenges?

    Chunikhin: There are several key capabilities that organizations should be looking at:

    • Portability and vendor-independence.
    • Extensibility and openness, i.e. compatible with widely used modern DevOps standards.
    • Easily deployable business components (such as data storage systems, deployment and release cycle automation tools, application server clusters, etc.)
    • Ease-of-use and immediate readiness for production deployments.

    That’s a lot to check off, but key to this approach is a combination of best practices and the use of open-source DevOps containerization and cloud technologies such as PaaS. PaaS is critical here since it uniquely provides the extensible and ready-to-use pluggable infrastructure services needed to easily configure new services, introduce development efficiencies and take care of the operational concerns that can impinge any DevOps strategy.

    DevOps automation and container orchestration technologies also augment cloud strategy and multiply its benefits by an order of magnitude.

    About the Author /  Wolf Ruzicka

    wolf-ruzickaWolf Ruzicka is chairman of EastBanc Technologies, joining the company in 2007 as CEO. During his tenure, he has overseen the organic growth of the company, taking it from 35 employees to more than 150, with staff turnover of virtually zero. He serves on numerous boards and groups, including the Microsoft Customer Advisory Board for Microsoft Azure and the World Economic Forum’s “Partnering for Cyber Resilience” initiative. Prior to joining EastBanc, Wolf served as president of APIphany (now part of Microsoft) and held leadership positions with MicroStrategy, Mercedes Benz, Lufthansa and more. Wolf holds an Master of Business Administration from Ingolstadt School of Management.

  • The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

    The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

    Containerization and microservices seemed to have leaped out of nowhere and smack into the center of the enterprise IT scene. But neither leaped from nowhere. Both containerization and microservices have been part of the fabric of enterprise tech for some time—within Linux for containers and service-oriented architecture for microservices.

    Largely, thanks to containerization, both now are moving quickly to become central components of enterprise tech. Containers in recent years—and especially in recent months—have moved from tools used in development environments to production. And the ability to manage containers as discrete services is enabling enterprises to be able to respond quickly and be agile to technology demands.

    According to a recent survey from app performance vendor NGINX, of roughly 1,800 IT professionals, while container and microservices software adoption is limited it’s use is accelerating. The survey found that only 20 percent of respondents said they are using containers in production, while about one-third are doing the same for microservices.

    That survey, not surprisingly, indicated that microservices and container use will continue to accelerate, as roughly two-thirds of respondents said that they are currently evaluating containers and 70 percent microservices.

    Microservices are workloads that perform a single task and they are not dependent on the infrastructure or other applications for their ability to complete their designated task or “service.” Microservices are very effective at providing enterprises the ability to rapidly build software that solves business problems. They also make it possible for development teams to scale their efforts and build a more resilient architecture.

    With all of that in mind, and considering the nature of the inflection point most enterprises find themselves in now, we’ve assembled this microservices and containerization survival guide. The guide consists of some of the most important storage on microservices and container management that we’ve ran in the past year.

    DevOps Teams: Containers Will Help You Become Future Ready

    According to The State of Containers 2015 Docker Adoption Survey, more than 70 percent of respondents are either using Docker or evaluating for future use. Given the overwhelming popularity of containers, this post provides three trends that DevOps teams must be prepared for.

    7 Web Interfaces for Container Management and Orchestration

    Managing containers used to be a command-line affair. But a rich and growing ecosystem of web-based interfaces for containers has now emerged. This post provides an overview of the different web UIs available for container management and orchestration.

    ‘Containers-as-a-Service’ Is a Hot Trend

    Containers are still sort of the new kid on the IT block, but already containers-as-a-service is emerging as a thing. Here’s what you need to know.

    A Closer Look at Container Monitoring

    Enterprises have to ensure that all of their microservices perform well and provide their services as designed. Beyond that, how much do they really need to know about what’s going on inside their containers? The answer to this question varies. In this post Gerald Haydtner provides an overview for container-monitoring options.

    Containers: Not One to Rule Them All

    When it comes to the container platform ecosystem, not all container platforms are created equal. This post will help you sort through the options.

    Building Microservices: A Few Considerations

    An experienced practitioner details the top five design considerations when building microservices.

    5 Docker Best Practices You Should Follow

    Support for Docker has been integrated into many products and platforms and a lot of organizations are either already using Docker containers or trying to understand how to do so themselves. Our Tony Bradley provides the Docker best practices one needs to know to succeed.

    How to Choose a Cloud Platform for Containers

    Containerization has broadened from one or two vendors to a broader, more container-agnostic world and a drive to better scalability, redundancy, interoperability and security. Amazon, Google and Microsoft each have their own unique approach to addressing these cloud container concerns as they battle each other for supremacy. Here’s a look at how to evaluate each.

    Container Security: Why Bother?

    Are containers secure? Probably not. But knowing each approach’s strengths and risks—and available options—could help ease adoption.

    Container Security Challenges: Are Container Scanners Enough?

    How secure are containers? Not very, according to open source company Red Hat, which has published a blog post blasting the container ecosystem for lacking good security processes. Here’s a synopsis of what Red Hat has to say about container security, and some additional perspective.

    For Container Security, Automation Is Key

    Regardless of the IT infrastructure element in question, if it connects to a network—even through proxies or human intermediaries—eventually someone will find a security flaw and exploit it. Compatibility issues with new applications or infrastructure elements will emerge. Because of these reasons, all IT infrastructure elements need to be managed, without exception.

    Containers and Security Q&A: Putting a Lid on Risk

    How do containers affect security? And how can IT teams do everything they need to do in order to ensure the containers in use are as secure as they reasonably can be?

    — George V. Hulme

  • Top 10 IT Management Tools

    Top 10 IT Management Tools

    Staying up with the latest IT management tools is akin to keeping up on the latest Starbucks drink options. We simplify it here through a look at the most useful tools, from monitoring to DevOps orchestration and APM.

    IT management tools have entered a new heyday, thanks to the advent of cloud, DevOps and mobile computing. With all of the new types of infrastructure, software and development methods, developers and IT managers need simple automation to get through the day. But with hundreds of IT management and DevOps tools on the marketplace today, both open source and commercial, it’s hard to know where to start.

    The global DevOps tools market alone is expected to be worth $3 billion by 2019, according to Technavio. While there are many applications to choose from, we have compiled a list of our favorites below. Some of these are tried and true, while others are newfangled and still in their early days of experimentation.

    Microsoft System Center Operations Manager (SCOM)

    IT Operations Management and IT Service Management

    Microsoft SCOM is a legacy enterprise infrastructure monitoring and management tool that delivers comprehensive coverage for the Microsoft ecosystem of assets and devices, whether they are installed on internal data centers or in the cloud. SCOM has evolved over the years to monitor network and storage along with Unix-based systems.

    Cautions: Since SCOM is a deep monitoring tool that collects data from many different systems, it generates a large volume of data and alerts that can overwhelm systems administrators and IT managers.

    Vistara

    IT Operations Management and IT Service Management

    Vistara is a comprehensive tool for monitoring heterogeneous multivendor assets and devices, whether installed on-premise or in the cloud. It covers a wide swath of Microsoft and Unix applications and systems, major enterprise vendors such as Oracle and Symantec, and top storage and networking technologies. Vistara also integrates well with other monitoring tools. A unique feature of Vistara is that it records all user sessions, which provides an audit trail for tracing system changes and other events.

    Cautions:  Vistara is a powerful, multifunctional tool and needs to be set up properly to derive the maximum benefits.

    SolarWinds

    Network Monitoring

    SolarWinds is a leading tool for managing and monitoring performance of a multivendor distributed network environment. The tool delivers a lot of useful metrics, including performance, capacity and downtime. It is particularly useful in companies with many locations, such as a retail brand, or a national or multinational company with a large number of branch offices and locations.

    Cautions: SolarWinds does not provide comprehensive monitoring for servers or storage systems.

    (Editor’s Note: SolarWinds reached out to devopsy.kinsta.cloud to clarify that it does offer comprehensive monitoring for servers and storage systems through its Server & Application Monitor and Storage Resource Monitor tools.)

    Nimsoft (CA)

    Network Monitoring

    Nimsoft is another excellent network monitoring tool, but is best-suited for an on-premise (internal data center) environment that has standardized on a few types of equipment and has a low rate of change. A company that is adding new technologies and devices frequently won’t find the tool to be flexible enough to adapt to evolving needs.

    Cautions: This legacy tool is not ideal for diverse and fast-changing IT environments.

    ServiceNow

    IT Service Management

    ServiceNow is well-known in the industry for comprehensive service management, including service level management, financial management, incident management, availability management, change and release management and more. ServiceNow has the broadest coverage for all ITIL activities, making it the de facto standard for service management and suitable for use in small companies up to the enterprise.

    Cautions: Because this tool is so flexible, you can easily customize it to meet your organization’s specific needs. Beware that by doing so, you’ll need a full-time administrator to manage the customized system.

    Chef/Puppet

    DevOps Automation and Management

    When it comes to tools for managing cloud application development and deployment, Chef and Puppet have near-cult status among developers. Companies occasionally use them both, but there is overlap between the tools. Chef is ideal for DevOps provisioning, orchestration and configuration management and is a more flexible platform overall, featuring auto rollback to previous versions. Chef also provides real-time visibility into metrics and messages. Puppet is best for DevOps automation and administration and is a highly prescriptive, process-driven platform that does not allow shortcuts, which should make IT Operations people happy.

    Cautions: Chef and Puppet are used primarily by developers, not IT Ops, and therefore raise some level of caution if developers are spending too much time managing the tools vs. writing code.

    Docker

    DevOps/Containerization

    Docker is the industry-leading tool for DevOps automation of application deployment inside software containers. It can be used for nearly any software project and infrastructure environment, and is especially helpful for managing dependencies and version inconsistencies. The application is a game-changer for simplifying the complexities of deployment. Docker containers wrap up a piece of software in a single, portable unit that contains everything it needs to run: code, runtime, system tools, system libraries and so on.

    Cautions: Docker’s approach to security is still unproven, and some believe it is not up to enterprise security standards.

    Apache Mesos/Google Kubernetes

    DevOps/Clustering

    Apache Mesos is best for cluster management and utilization for distributed applications in a DevOps world, while Google Kubernetes is ideal for automating deployment, scaling, and operations of application containers across clusters of hosts. Clustering tools sit on top of hardware and increase utilization through effective workload management and resource-sharing. They work in both public and private cloud infrastructure environments, across many different platforms, and allow IT organizations to run more workloads on the same hardware. While both of these tools are fairly new, Mesos has been around longer and is more appropriate for large environments with heavy management and scale needs.

    Cautions: When looking at small clusters of say, fewer than a dozen nodes, Mesos may be an overly complex solution.

    New Relic

    Application Monitoring

    New Relic is well-known for its real-time capabilities in monitoring and managing web and mobile applications within cloud, hybrid and on-premise infrastructure. For an APM tool, New Relic is strong at identifying server-based performance issues. It also allows for real user page performance tracking so you can see if certain classes of users (for instance, by region) are having worse performance than others.

    Cautions: New Relic does not capture 100 percent of transactions, but does a sampling. This may or may not be important depending upon your business needs. It is also somewhat rigid, and may not be too flexible in an environment that has a lot of microservices.

    Graphite/Grafana

    Dashboards

    Graphite and Grafana are two leading graph and dashboard builder for visualizing time series metrics. The tools are particularly useful for analyzing metrics and other types of data from on-premise systems, public cloud, private cloud and IoT systems.

    Grafana is most commonly used for visualizing time series data for Internet infrastructure and application analytics but is also used in domains including industrial sensors, home automation, weather and process control.

    Graphite is excellent at visualizing data and metrics.

    Cautions: You will need a complex and elaborate configuration of databases to gather the data and a compute engine to generate the dashboard.

    About the Author/Ravikumar Raghavenderrao

    ravikumar-raghavenderraoRavi RRK, as he is known, is the Vice President – Service Delivery at NetEnrich. Ravi’s responsibilities include service delivery management, customer satisfaction, and new service introduction. Ravi’s team also has the responsibility to ensure and enforce quality and policy standards across the NetEnrich organization.

    Ravi has over two decades of experience in the IT industry in the areas of remote infrastructure management, delivery and large account management. Prior to joining NetEnrich, Ravi spent over 20 years at Wipro Technologies in various positions. Ravi holds a Bachelor of Engineering (Mechanical) degree from Osmania University and a Master of Engineering (Mechanical) degree from the Indian Institute of Science.

  • DevOps Debates: Image-Driven or Build-Driven Delivery

    DevOps Debates: Image-Driven or Build-Driven Delivery

    In the last 12 months, Docker and the containerization paradigm has challenged the foundation of some of the software delivery principles. People are resorting to things that were unheard of 18 months back and are now using them to successfully deliver software faster and cheaper. One such thing is the debate around build-driven delivery vs image-driven delivery.

    Over the last few decades, software has been packaged and built by a build system and tagged with a number; testers aligned their testing to the tag as the entity being tested and promoted them until it reached production. The build number was one of the most important tag for anyone to communicate about the status of the software in the delivery pipeline.

    For some time now—primarily due to Docker—several teams are moved to a methodology in which the image defines the version of a software. Every change in application program and deployment program will together create a new image, which is tagged and used as the version of the software to be launched for downstream use and finally into production.

    The debate then is, which option is better?

    Let me take a shot at this, and will invite your thoughts on this as well.

    For builds-driven delivery:

    1. Builds helps software to be tagged irrespective of the target hardware and other deployment options. It bundles all dependencies to ensure the software works when deployed to the expectation. This provides the development team a good hand-off point to move on to the next set of work, or sprint.
    2. Builds are much smaller in size, as the build bundles only necessary software needed by the application; hence, keeping them aligned with every change will not be a costly storage proposition.
    3. Versioning of artifacts and bundling them at run time has given tools such as maven to build and link dynamically, collecting all dependencies from the cloud. This makes it easier to keep a thin build and further reduce the redundant data to be kept in each build.
    4. Build repositories have matured over the years to provide a very easy way to version and mark dependencies so deployment tools can find new versions and automatically upgrade environments as needed.

    For images-driven delivery:

    1. Images takes the concept of build to the next level and ensures the variability in target hardware and deployment options are removed completely. It bundles the application as given in the build or built as part of the image creation and pushes the image as a build.
    2. Docker registries have started to compare and contrast themselves into a build repository by providing similar options for end users.
    3. The images-driven option provides a much better benefit of standardizing all your environments, removing the question,”It works in my environment; does it in yours?” If it works in the container in a developer’s laptop, it should work in production as well—everything is same, except for the size and number of resources.
    4. Images are much larger than builds, given that it has to now carry the system software and the application base software within the image. This option was unheard of earlier, but with container images coming down to megabytes, this is not such a big issue today. With layering sizes can be reduced much further as you start peeling the onion of dependencies. Take a look at this nice article by Brian on this topic.

    I guess the choice depends on where your application is in its life cycle, the questions teams should really ask are:

    a) Do we need to change too much to pick an option for an incremental benefit?

    b) Do I have the issue of environmental differences?

    c) Can I merge these options to get a hybrid solution going?

    But for me the larger question is, Which option would you choose, if you were starting from scratch tomorrow? I would love to hear your thoughts.

    Finally, irrespective of which way you lean, image-driven solutions is one of the best way to bring DevOps culture to a team: If the image works, the team has won; it doesn’t matter whether it was ops code or dev code!