devopsy.kinsta.cloud

Tag: application development

  • Securing Third-Party and Open Source Code Components: A Primer

    Securing Third-Party and Open Source Code Components: A Primer

    The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

    Sacrificing Security for Ease of Use

    While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

    Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

    Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

    Where Does Responsibility Lie?

    One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

    This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

    How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

    • Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
    • Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
    • Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.

    While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

    — Pete Chestna

  • More App Dev Models Increase DevOps Pressure

    More App Dev Models Increase DevOps Pressure

    A bifurcation in types of developers will become more pronounced in the years ahead as more application code moves to the network edge. As that transition continues occurring, the pressure on IT operations to be able to be able to flexibly manage different classes of applications by embracing DevOps processes will correspondingly increase.

    Mike Piech, vice president and general manager of middleware for Red Hat, said applications running on internet of things (IoT) devices and smartphones present developers with a finite amount of compute resources that require them to have advanced skills. Conversely, back-end applications can now take advantage of multiple layers of abstraction, including (soon) serverless computing frameworks based on event-driven architectures that make potentially unlimited compute resources available. The availability of all those compute resources, however, encourages developers of back-end services and applications to be less disciplined when writing applications.

    The good news is that it’s getting easier to right-size applications using trial and error methods versus having to commit to a specific computing architecture up front, said Piech. If something doesn’t work as well as it should, modular approaches to microservices make it possible to more easily move application code to where it should best optimally reside. Rather than focusing on the rigor of the underlying architecture, developers are free to experiment with different tools and languages more now than any time in the history of IT, he said.

    In fact, Piech speculated that many graphical user interfaces will continue to run locally while accessing a wide variety of back-end services via application programming interfaces (APIs). That approach essentially creates a new form of hybrid computing wherein developers no longer need to think much about the runtime environment, he noted.

    However, all that freedom tends to put a lot more pressure on the IT operations team. As the types and classes of applications continues to evolve, Piech said it’s only a matter of time before more organizations move further down the DevOps path. Adoption of DevOps processes across organizations has been somewhat uneven. But as developers experiment with different computing models, the expectation is that operating teams will be flexible enough to dynamically make the appropriate adjustments, he said.

    Longer term, middleware and databases will eventually be deconstructed into sets of microservices that developers can call when needed. Today, IT operations teams make available monolithic application servers and databases. Many of those databases and application servers are starting to be encapsulated in Docker containers as part of a first step toward lifting and shifting applications into the cloud before transitioning to more agile microservices-based frameworks, Piech said.

    In some cases, those services will be accessed directly via a platform-as-a-service (PaaS) environment or a serverless computing framework. Piech said Red Hat expects serverless computing frameworks based on event-driven architectures will be used mainly to provide bursting capabilities as a complement to long-running stateful applications that typically consume a fixed amount of IT infrastructure resources. It’s probable stateless applications that run intermittently also will find their way on to serverless computing frameworks. Red Hat has thrown its support behind the open source OpenWhisk serverless computing framework.

    There clearly will be many more types of distributed applications running across the enterprise. IT operations teams may not have much control over what types of applications run where and when. But they will be expected to be able to deploy and manage them all, regardless.

    — Mike Vizard

  • Akamai Extends Scope of DevSecOps Reach

    Akamai Extends Scope of DevSecOps Reach

    Akamai pressed its case for becoming a strategic DevSecOps platform by adding a range of security capabilities to its network service platform that help isolate applications from cybersecurity threats.

    The company has added support for scripting to automate application security using its Kona Site Defender web application firewall as well as improved management and versioning support for application programming interfaces (APIs). Those capabilities complement an Akamai API Gateway for securing and managing APIs.

    Akamai is also updating Akamai Bot Manager, adding a client SDK for mobile applications to help mitigate distributed denial of service (DDoS) attacks. The company also is adding capacity to its scrubbing centers to further defend against large-scale DDoS attacks.

    Ari Weil, vice president of product marketing for Akamai, said the company is evolving into a platform that securely provides web applications with access to caching software and network infrastructure that dynamically scale up and down as required.

    The goal is to make the Akamai network a seamless extension of any DevOps processes that developers can programmatically invoke on demand regardless of whether their applications reside in a public cloud, on-premises or in a third-party hosting center, said Weil. Because Akamai sits between users and production applications, Akamai now plays a critical role in terms of bother DevOps and DevSecOps, he said.

    In term of accomplishing that goal, Weil conceded Akamai doesn’t have as much visibility in the DevOps community as it would like. The company has integrated its platform into continuous integration/continuous development (CI/CD) platforms such as Jenkins to reduce as many steps as possible for DevOps teams. But developers are not always fully cognizant of the security services that Akamai makes programmatically available, he said.

    Weil noted that as DevSecOps continues to gain ground, Akaimai expects many developers will increasingly appreciate those security services, especially as cyberattacks become both more frequent and lethal. A 2017 security report published by Akamai finds DDoS and web application attacks rose 14 percent and 10 percent, respectively, year over year.

    In effect, Akamai turns web application security into a large-scale zero-trust managed service that is available on thousands of points-of-presence (PoPs) around the world. In time, developers will only have to express their intent concerning the level of security to be applied. The execution of that intent will all be automated, Weil said.

    In an ideal world, all cybersecurity battles would be fought as far away from applications as possible. Rather than focusing solely on the edge of the corporate network, Akamai is encouraging DevOps teams to think in terms of layers of defense that starts where applications are cached at the edge of the network. In theory, platforms such as Akamai provide a lot more visibility into what types of cyberattacks are circulating in the wild hopefully long before they ever get a chance to impact an application. The challenge, however, lies in distinguishing between what security technology needs to be embedded in the application itself versus an on-demand service that’s only a simple API call away.

    — Mike Vizard

  • Code Yellow: When Operations Isn’t Perfect

    Code Yellow: When Operations Isn’t Perfect

    Every now and then, engineering teams will get into trouble for any number of reasons. Sometimes, explosive growth catches the team by surprise. Or, on-call has gotten out of control, with alerts going off every five minutes. Or, development and operations teams simply have stopped seeing eye to eye. Regardless of why, the team is in a bad spot and something needs to be done to resolve it.

    If it’s a new problem, the fix might be easy: Add a few more servers, roll back to a known good application version or get everyone together over pizza and beers to clear the air. Often, however, the problem creeps up on you over time and suddenly the hole is so deep you can’t find the way out. At LinkedIn, a team that has gotten to this point will often declare a state known as “Code Yellow.”

    Yellow Alert

    Some people assume the name Code Yellow is based on traffic lights, but more accurately—and with a geekier twist—it’s actually from your favorite “Star Trek” series. More precisely, it’s how the crew of the Starship Enterprise indicates their current defensive condition. Either way, the definition is clear: Something is wrong, and we need to move forward with caution. True to both metaphors, we also have a Code Red. That’s better described as an immediate crisis, with everyone working 24 hours a day until it’s resolved. The Code Yellow is slightly more laid-back: This is everyone’s primary focus, but during business hours only. Code Yellows also tends to last on the order of months, while a Code Red should last on the order of days.

    Other companies may use a different term than Code Yellow, but the effect is the same: The team is communicating to the rest of the company that they’ve identified a serious problem that is a priority to be fixed to ensure the success of the team and, therefore, the company. The ability to do this is an important aspect of open and honest communication, a value that is critical to a healthy culture and can often get overlooked. Talking about our problems is just as important, if not more so, than celebrating our successes. Teams can learn more from fixing a problem than they can from a total success.

    This is Not a Failure

    The first step in starting a Code Yellow is to understand this is not a failure. There is no shame in admitting that the team has a problem that needs to be fixed. Bugs happen, despite our best efforts to avoid them. The only thing we can do is diagnose the problem and remediate it. The only time we fail is when we turn a blind eye to these problems. This applies to how our engineering teams interact with each other just as much as it does to the software and systems we produce and run.

    It is critical, however, that the right problems are addressed. Most of the time, we’ve gotten into the current situation because of a slow boil—increasing technical debt, many small issues or breakdowns in a process—that eventually built up into a crisis. The goal of the Code Yellow must be to not only remediate the current problems (a reactive component), but also make sure they are not repeated in the future (the proactive component).

    Planning for a Successful Code Yellow

    There are several components required for a successful Code Yellow, as well as necessary pieces to get buy-in from the rest of the organization:

    • Problem Statement: There must be a clear and agreed-upon statement of the problems facing the team that prompted the Code Yellow. This should include not only what the current problems are, but also what the current understanding of their root cause is.
    • Exit Criteria: Next, you need to have specific goals that the team will work toward to exit the Code Yellow. These should be traditional SMART goals: specific, measurable, achievable, relevant and time-bound. These goals are what make it possible for the team to enter a Code Yellow in the first place, as it covers a fixed scope and is not open-ended.
    • Communication: All information about the Code Yellow, including the announcement (which includes the problem statement and exit criteria), the successful conclusion and periodic status updates should be sent to the larger organization. This may be your department, or it may be the entire engineering organization. It may even be the entire company, depending on the nature of the problems.
    • Project Management: Like all large projects, there needs to be someone responsible for organizing the work and communicating information. As this represents an “all hands on deck” scenario for the impacted team, it is usually helpful to have a dedicated project manager (PM) to help with this. This is typically a PM who is knowledgeable about the team and the work, but not directly involved with the execution. This frees up the managers and individual contributors to focus on the work at hand.

    Once each of these aspects have been thought about, and the decision has been made to enter Code Yellow, the team’s first act is to reorganize their priorities around the exit criteria. This often means putting quarterly goals on the shelf. It may also be necessary to establish a dedicated meeting around discussing the status of the exit criteria.

    Space to Breathe

    It is all well and good for a team to enter Code Yellow and work with a single focus on the goals that have been set to make things right, but this is not enough for the team to succeed. For true success, everyone surrounding the team must understand the situation and give them the space to do their work. This is the place where a healthy engineering culture rises to meet the challenge.

    • Expect Delays: The most common way that a tangential team will be affected is through delays. They must expect that any requests that have been made of the impacted team may be delayed if they are not within the scope of the exit criteria. The Code Yellow involves, at its core, a reordering of priorities to address the stated problem. Outside teams need to factor this in and understand that their own project timelines may need to be adjusted.
    • Minimize New Requests: Other teams should also refrain from asking the impacted team for new things that are outside the scope of the defined exit criteria. Minimizing these requests, in addition to accepting delays on any existing requests, allows the impacted team to spend their limited engineering hours on getting to the other side of the Code Yellow.
    • Requests for Assistance from other teams: The team in Code Yellow may find they need outside help to reach their goals. For example, if there is sudden, explosive growth in traffic, they may need to accelerate the provisioning of new hardware. Finding yourself on the receiving end of a request such as this may require shifting your own priorities. Always remember that the team is all part of the same company, and as such, everyone succeeds or fails together.

    Engineering teams rarely stand alone, and it is important that everyone understand the value in having those teams working well, and working together well. A little temporary delay in goals to assure that this is the case is well worth it.

    Light at the End of the Tunnel

    Code Yellow represents a significant amount of high-priority work and working through it will often be stressful for the team. Saying “no” to coworkers that are making a reasonable request is hard, and the work that is in scope rarely involves spending time on interesting new features. In addition, if the problems being addressed include communication issues between groups, there are going to be some difficult conversations that need to happen. However, as the team approaches the end of the work, it will be much easier to see through to what lies on the other side of the exit criteria.

    The ultimate goal of the Code Yellow is to get the team out of a reactive mode where they are running from crisis to crisis and into a proactive state where they are able to work on the right big projects. Achieving the exit criteria will mean the engineers are more effective and able to work proactively. This is a stronger team—engineers are happier because they’re not under a heavy stress of operations work, the team is working well because they’re talking to each other effectively, and customers are pleased because requests are handled either through automation or in a reasonable amount of time.

    Does your company have an internal process that’s similar to how LinkedIn does a Code Yellow?

    — Todd Palino

  • HashiCorp Extends Secrets Management Reach

    HashiCorp Extends Secrets Management Reach

    Secrets management is core to DevSecOps—how credentials are managed can make all the difference in preventing an application from being compromised in the first place. The challenge is making it as simple as possible for developers to access where most of those credentials are stored in the enterprise.

    HashiCorp this week released an update to the open source Vault secrets management software that adds support for both the Microsoft Azure Active Directory Auth Method and the identity and access management (IAM) engine used in Google Cloud Platform (GCP). Those new capabilities complement existing support for LDAP, Amazon Web Services IAM, Kubernetes, GitHub, Okta or others.

    In addition, version 0.10 of Vault adds support for a graphical user interface (GUI). Previously, the GUI was available only in the enterprise version of Vault that HashiCorp supports. But Andy Manoske, a product manager for HashiCorp, said organizations are making it clear they want developers and cybersecurity professionals to make use of the same core secrets management framework. Because most cybersecurity professionals don’t know how to program it became necessary to add a GUI to the core Vault open source software, Manoske said.

    In general, Manoske says developers and cybersecurity professionals are starting to work more closely together. Microsoft Active Directory is the most widely used platform for storing credentials. As enterprise IT organizations start to move more Windows applications to the cloud, enabling developers to programmatically access the credential data is becoming a bigger requirement, he said.

    Additional capabilities in version 0.10 of Vault include the ability to automate the rotation of root credentials at specified intervals and support for versioning. That latter feature is critical for both compliance and disaster recovery purposes, as well as enforcing temporary changes to secrets keys during the investigation of a potential cybersecurity breach, Manoske said.

    From a DevSecOps perspective, Manoske said the biggest challenge remains the reliance on manual efforts to manage secrets within the applications rather than storing them externally in a secrets management platform. Cybercriminals increasingly are making use of automation tools to scan applications for vulnerabilities that enable them to compromise credentials. Vault provides a means for managing credentials that encrypts credentials that can be applied across thousands of applications at scale. It’s hard to see how organizations can address application security without finding some way to automate secrets management, he said.

    Progress in DevSecOps so far has been slow, but steady. Most organizations won’t be able to address DevSecOps effectively until they master DevOps fundamentals. Once that occurs, organizations need to establish a workflow between developers who want to address every function with application programming interfaces (APIs) and cybersecurity professionals that define corporate policies.

    Embracing DevSecOps is, of course, as much about the processes and culture as it is about new technologies. The real challenge is finding a way for developers and cybersecurity professionals to collaborate without seriously compromising the rate at which applications are being developed.

    — Mike Vizard

  • The Need for Rapid Development in a Post-App World

    The Need for Rapid Development in a Post-App World

    Gartner’s May 2017 report, “Preparing for a World Beyond Mobile Apps,” anticipates a post-app environment in which consumers have a wide variety of interfaces to choose from—including wearables, bots, ambient voice interfaces, IoT devices and AR/VR—that not only lend themselves to more immersive and seamless digital experiences, but also upend how businesses need to think about developing and delivering experiences. The post-app world, which we’ve begun to see accelerating in 2018, requires a major shift toward a rapid development framework at a time when agile methodologies are becoming overly costly and time-consuming.

    Examples of the types of experiences requiring rapid development often surface in highly competitive areas such as retail.  Examples include a luxury car dealer greeting customers with a large wall display with depth-sensing 3D camera, gesture-based interface and face recognition. As the customer gestures around the screen, an application recognizes his face, alerts the service manager that he’s there to pick up a car from repair, and harnesses his sales history and its loyalty program to make a special offer if appropriate.

    Then there are highly scalable opportunities to offer better capabilities while lowering costs such as chatbot technologies for interactions with vendors and suppliers and numerous HR functions. Retailers such as Gap, Target and Ralph Lauren have started incorporating digital augmented reality, interactive mirrors, beacons and other advanced interactive interfaces to enhance the physical shopping experience.

    Immersive experiences and physical/digital blending calls for a rapid development framework in which developer resources are utilized on infrastructure but not wasted building custom features that can be easily integrated via pre-built modules. This frees developer resources and allows lines of business to have more influence on the resulting experience.

    Rapid development also demands a unique mix of emerging strategies, tools and technologies to achieve the best immersive user experience fast:

    Design Thinking

    To paraphrase Steve Jobs, design thinking is not about how a device, software product or business process appears, but how it works. It requires thoroughly understanding and empathizing with the user’s needs and continually coming up creative ways to meet them, so the interaction is not only immersive but effortless. Design thinking must involve the user—whether customer or business—and must be a process of continuous exploration, prototyping, feedback, evaluation and optimization. Even then, innovation continues as needs change and evolve.

    The ultimate goal of leading with design is to keep the focus on ensuring a superior user experience.

    Microservices

    Microservice architectures allow teams to continually optimize individual components of a larger application without affecting others, thanks to loose coupling, REST and real-time APIs. Scores of application components may exist on-premises or in the cloud and can interact and pass data back and forth easily but each is limited to one or a few functions. Since changes and optimizations in one component don’t necessitate significant changes in the others, teams can optimize each function continually without having to re-engineer an entire application infrastructure. These components can also be shared with other applications if necessary.

    Agile Engineering

    Agile engineering is one component of rapid development, rather than the primary focus, and the goal should be improving the connection between the rapid process of design thinking and quickly evolving microservices and the challenges of software engineering. Even in an agile process the DevOps cadence required to deliver robust and secure software requires multiple sprints of two to four weeks in length. In successful projects, the majority of the layout and workflow falls onto the rapid development side. Then, the investment in additional time and resources is only required for the remaining elements that need an additional level of control and engineering rigor.  Agile engineering is the perfect partner for design thinking as it is designed around the ability to accept well specified requests into backlog and turn them around with high quality in the minimum number of cycles.

    The Way Forward

    Rapid development tools enable quick prototyping, deployment and easy continuous integration with existing systems. Intuitive editors and extensive libraries of application components and immersive interfaces such as VR, AR, personal assistants and IoT components enable developers, business users and designers to pull together prototypes of post-mobile components in hours or days. This allows quick feedback and evaluation at very low cost.

    Developers can then extend and customize the prototypes further via scripting so they become the actual production system. The best come tools with an ample supply of connectors and APIs to link with existing systems and run natively on many different mobile platforms, devices and displays. The right tools can accelerate innovation and cut costs dramatically.

    Radical digital transformation has arrived and organizations will have to adopt post-mobile technologies to compete. The right mix of tools and strategies will be key to redefining the enterprise development process from application-based to immersive-experience-based regardless of device, operating system or infrastructure.

    — David Brebner

  • Hackathon: DevOps Q&A with Appian VP Malcom Ross

    Hackathon: DevOps Q&A with Appian VP Malcom Ross

    Hackathons are a great way to demonstrate the value of a platform. I had the chance to speak with Malcolm Ross, vice president, Product at Appian to share a bit more about Appian’s virtual hackathon to correspond with its upcoming user conference.

    Full disclosure: I’ll be one of the judges attending Appian World to judge the finalists, so hope to see you all there!

    Alan Shimel: Can you share a high-level overview of the Hackathon?

    Malcolm Ross: Appian is holding its first online hackathon in conjunction with DevPost to correspond with our upcoming Appian World conference in late April. We’re looking forward to seeing how participants are able to build and deploy powerful enterprise apps with Appian’s low-code cloud development platform.

    Shimel: Who could apply for the Hackathon?

    Ross: Whether they’re an existing Appian customer or not, we challenged anyone to build a new app on the Appian platform that enables their business to do more. There’s no specific theme—just show us something that improves their team’s performance and drives enterprise innovation! We asked all participants to submit their applications by March 27 along with a demo video (hosted on YouTube, Vimeo or Youku). This should incorporate a step-by-step visual demo, and additionally, a way to access the working application for judging and testing. Anyone interested in participating received a free 60-day instance of the full Appian Cloud platform to support their development efforts.

    Shimel: Who judges the winners?

    Ross: A panel from Appian will score all eligible submissions to determine the top three finalists. Finalists will be notified by April 13 and given the opportunity to demo in-person or remotely to an all-star panel of judges, including Apple co-founder Steve Wozniak, Forrester analyst John Rymer and yourself, Alan! We’ll also have some Appian executives involved in the process including ‎Senior Vice President for Strategy Lang Ly, Chief Technology Officer Michael Beckley, Director of Product Strategy Jorge Sanchez and myself.

    Shimel: What are the evaluation criteria for the selection of the winning team?

    Ross: It’s pretty open-ended for participants to come up with their own innovations. The main requirement was that the users must build a functioning app on the platform by March 27. More about the criteria can be found here.

    Shimel: What are the awards?

    Ross: There are three cash prizes ($5,000, $3,000 and $2,000) along with admission to Appian World 2019 and promotional of the submissions by Appian on the Appian AppMarket.

    First place will receive $5,000 cash and four free passes to Appian World 2019, and the Appian Deluxe Promotion, which includes a featured promo on Appian.com, Appian AppMarket (if the app is in the market) and Appian Community, joint webinar and collateral, a blog post on Appian.com and a press release.

    Second place will be awarded $3,000 cash and two free passes to Appian World 2019, and the Appian Promotion, which includes a featured promo on Appian AppMarket (if app is in the market) and Appian Community and a blog post on Appian.com.

    The third-place prize is $2,000 cash and one free pass to Appian World 2019, and the Appian Promotion, which includes a featured promo on Appian AppMarket (if app is in the market) and a blog post on Appian.com.

    Shimel: What is the timeline for the Hackathon?

    Ross: As mentioned, the deadline for entry was March 27. We’ll make sure to notify finalists by April 13 so they have some time to book travel if they would like to meet our all-star panel of judges for the conference. Final judging will be held on April 25 at the Fontainebleau Hotel in Miami Beach, Florida.

    Shimel: Where can people find more information about the Hackathon?

    Ross: Anyone who’s interested can find more information about Hackathon at Appian.devpost.com or learn more about our Appian World conference at appianworld.com.

    — Alan Shimel

  • Building a Solid Foundation for Microservices Security

    Building a Solid Foundation for Microservices Security

    It’s often true that threats evolve faster than development practices and technologies can keep up with, which can be seen in the current microservices approach to application development. While microservices bring clear benefits to developers by enabling application deployment via modular, independently deployable services, they also open the door to new security vulnerabilities.

    Consequently, these changes in the approach to software development require a change in the mindset of developers regarding how they think about and implement security. Security now must be a core component of each service—security that can withstand the constantly changing nature of these interactive services. Each service must be a resilient and secure unit that is capable of interacting with other apps and services without compromising security. In addition, each service must be careful how it handles data at the edges to ensure every possible interaction can be secured, even when interacting with services that do not meet the required security standards.

    To fully address these security challenges, developers also need to change their mindset on how they approach privacy and security in their code. That means thinking of security from the genesis of the program and from within the code itself rather than relying on the infrastructure to secure the application. This approach enables developers to start their architectural decision-making by thinking of security as the foundation of their code, instead of as an accessory.

    Security from the Start

    In the bigger picture, DevOps teams must have full awareness and appreciation that there is no single approach to security, and that security and privacy considerations must be addressed case by case. Although there can be more, there are essentially five things that developers can do to make microservices security foundational to the development process.

    Compartmentalization

    First, developers must begin compartmentalizing the software development mission by attempting to make their microservices as essential as possible. Still, developers have to be careful not to go to extremes that result in the creation of a swarm of nanoservices performing a single task. The overall goal is to reduce responsibilities to the point where each single process lacks enough information to be a liability if it were to be breached.

    Encryption

    The role of encryption plays prominently in the new mindset for developers, so it’s imperative to utilize it on all of the data that each microservice needs and sending it on a perishable channel. This allows the cancellation of a compromised communication channel, rotation of the encryption keys used and retrying the message on a different channel or to a different node without worrying about a breach.

    A good example of this is a node where control has been lost in a high availability (HA) layout. By cancelling all message queues and resending the messages with a rotated key, it’s possible to continue functioning without worrying that the unresponsive node could be compromised and avoid a full stop.

    Disposable Channel Signing

    Developers will greatly improve their security posture in the software development life cycle (SDLC) by sending disposable channel signing and encrypting data to the services under their control. This will allow them to cancel credentials, and avoid data leakage, even when the control on the node is lost.

    Different Keys

    Developers are beginning to understand the efficacy in using as many different keys as may be needed since storage is a weak point in terms of encryption. The alternative is to use keys that are rotated regularly. This, however, requires going around the persistence solution and re-encrypting a lot of the data, which is not ideal. Besides, having layers of encryption will ensure that a single leakage from the storage keys will not grant access to plain data. Also, it’s important to use different keys for storage and transport, as re-encrypting on read is easy. This process avoids the need to spread keys and keep it tight.

    Key Access

    Finally, developers will benefit from making sure that all keys allow the minimum possible access while keeping in mind that they will need to tailor the time to live (TTL) as much as possible to the targeted use of each key. Although this approach may result in a complex permission schema, it delivers a massive reduction of the attack surfaces while adhering to security best practices.

    Conclusion

    Some of this may be common sense, and what is useful for one developer might not be sufficient for another. Generally, it’s good for developers to regularly challenge these suppositions on every service that they write, but the above formulated guidelines will serve almost every developer well by providing a stable foundation on which to begin their thinking. The universal viewpoint that they should all be taking is that security must be part of the DNA of their software.

    — Horacio Duran

  • Oracle Unveils Autonomous Cloud Service

    Oracle Unveils Autonomous Cloud Service

    Oracle today unfurled at an Oracle CloudWorld event what it describes as a completely autonomous cloud service the company will manage primarily on behalf of application developers.

    The Oracle Autonomous Cloud Platform is a managed service that makes extensive use of machine and deep learning algorithms across instances of Oracle software that can invoked on a public cloud or deployed in an on-premises IT environment, said Amit Zavery, executive vice president of product development for Oracle Cloud Platform.

    “We’re taking away all the day-to-day management issues,” Zavery said.

    The Oracle Autonomous Cloud Platform builds on the Autonomous Database service launched last year. This latest service essentially puts all the responsibility for managing IT operations on Oracle, which is relying on a major investment in machine learning algorithms to automate DevOps processes.

    The implications of that capability are profound for IT organizations, many of which Zavery said now will be able to shift more resources over to developing and maintaining applications. At a time when more organizations are focusing on digital business transformation, those organizations need to be able to free up resources to focus in application development, he said.

    Amit Zavery, Oracle

    Examples of how Oracle envisions the transformation of both DevOps and DevSecOps include chatbots that can be interacted with using natural language processing to automate repetitive tasks to automatically identifying and remediating security issues in code within the context of a continuous integration/continuous development (CI/CD) deployment. There are also controls to prevent data leaks across structured and unstructured data repositories, along with built-in security monitoring tools.

    Other capabilities include an ability to create data flows with automated data lake and data prep pipeline creation for ingesting both stream and batch-oriented data, as well as automating the integration of various on-premises and software-as-a-service (SaaS) applications.

    Advanced analytics tools span everything from automated data discovery and preparation to visualization tools for displaying trends.

    Oracle may have come late to the cloud computing game, but clearly it intends to make up lost ground by infusing higher levels of automation into cloud services that rivals don’t yet provide. Most cloud service providers are headed in the same general direction as Oracle. But the scope of automation being provided by Oracle, spanning both a public cloud and on-premises IT environments, is unprecedented.

    In many ways that level of automation may represent an existential threat to a larger number of IT operations professionals. At the same time, it presents an opportunity. IT professionals should be able to spend more time adding true value to the business instead of having all their time and energy consumed by merely keeping the proverbial lights on in the data center.

    Of course, it may take a while for most organizations to make a transition to a single stack of integrated hardware and software provided by a single vendor. Most organizations have decades worth of IT infrastructure consisting of databases, middleware, virtual machines, servers and storage systems all from different vendors. Even if organizations decided the time had come to rationalize those investments in favor of a suite of managed cloud services, it would take several years to make that transition.

    In addition, many organizations would also still need to evaluate the total cost of acquiring and managing IT infrastructure over several years versus contracting for services over the same period of time.

    Regardless of the path a company chooses, IT operations is about to be transformer utterly by artificial intelligence (AI)-infused automaton.

    — Mike Vizard

  • DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    In this DevOps Chat, find out how the developers of Wolfpack (wolfpack.run) are saving over 50 percent in cloud costs by using ParkMyCloud’s cloud management platform.

    Though the cloud offers many benefits to app developers and others, controlling the costs can sometimes elude organizations big and small. Cloud sprawl can quickly lead to large cloud bills. In this chat, we speak with Jonathan Chashper, CEO of Wolfpack, about how his company got a handle on the cloud and is spending less than 50 percent of what it was paying before.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 118815″ target=”blank” width=”200″ height=”200″]Chris Parlette
    Chris Parlette is the Director of Cloud Solutions at ParkMyCloud. Chris helps customers reduce their cloud waste and manage their hybrid infrastructures by drawing on his years of experience working at various software startups. From SaaS to on-prem, virtualization to cloud, monitoring tools to cloud management platforms, and small businesses to large enterprises, Chris has seen it all and loves helping drive improvements to IT management.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat is actually a great behind-the-scenes look at ParkMyCloud and how an app provider named WolfPack is using Park My Cloud to really kinda get a handle on their cloud costs, their cloud usage and optimizing the cloud for their applications.

    That being said, let me introduce you to our guest for today’s podcast. Our first guest is the CEO and founder of WolfPack, and his name is Jonathan Chashper. Jonathan, welcome to DevOps Chat.

    Jonathan Chashper: Thank you, Alan. Thank you for having me.

    Shimel: Thank you. And then our second guest is from ParkMyCloud, it’s Chris Parlette, and Chris, I hope I don’t mess up the title, but it’s director of Cloud Solutions?

    Chris Parlette: Correct, yes. And thanks, Alan, for having us—appreciate being here.

    Shimel: Not a problem. So, guys, this is gonna be a fun one, I think. Jonathan, why don’t you give our audience a little background—what exactly is this WolfPack app?

    Chashper: Sure. So, WolfPack, we are—you can look at us as a connected vehicle technology focusing specifically on helping individuals move together. Think about how much fun it is to move as a group. Imagine you are, you know, maybe several families moving in a few cars. It’s a lot of fun, but there are two major problems—one, keeping everybody together, making sure people don’t get separated, don’t get lost. And the second one is actually communicating with each other while traveling and doing it safely.

    Now imagine you are now doing it on model cycles, which is the first niche we’re focusing on. So, we’re solving those two problems with WolfPack, and by the way, people can take a look at WolfPack.run-R-U-N-to see how it works. But generally, what we do is, we provide, with a turn-by-turn navigation, to every one of the people driving or riding, while providing a radar showing the location of everybody else.

    So, we actually make sure that everybody gets there without being killed, without being lost, without getting into a ditch, and making the experience much less stressful, and much more fun.

    Shimel: And that’s a good thing. But Jonathan, well, you know, WolfPack represents sort of this new—it’s not really new. I’ve seen them now for a couple years, but I call them these instant group type of applications where you can create a group on the fly and that group can have two people or 200 people or more, right? And this group then does something. In the case of WolfPack, you know, they’re on a run or a trip of some sort, and you have Google Maps built into it or underlying it and, you know, all of these things, and they’re great.

    The problem is, as you probably are well aware, is you never know from moment to moment, you know, what your load is gonna be, right? How many groups, how big a group, you know, what’s going on?

    And so, in resource planning, that can be a problem. Talk to me—

    Chashper: Correct.

    Shimel: —yep. Talk to us a little bit about what you’re doing with ParkMyCloud and how that’s helping you.

    Chashper: Mm-hmm. Yeah, so you’re absolutely correct. What you said at the beginning, it’s true. We can—our users can immediately generate groups, it can be, they can generate any number of groups. It can generate—any group can have any number of people. They can plan a ride which can be as short as 10 miles or as long as 1,000 miles, so you’re absolutely right.

    And so, when we’re building the system, obviously, it’s a cloud based system. We are on top of AWS. What’s important for us is that the development costs, being a startup, is being-you know, kept to the minimum. And so, what we did, we actually looked into ParkMyCloud, and with ParkMyCloud, we got to the point that we control our development costs very, very tightly. Generally speaking, when you’re using a server in the cloud, as long as you don’t turn it off, it still works and you’re still being billed for it. And if your development teams go home-say, they work 9 to 7 every day, they go home at 7. If the servers are off, you’re still paying for them.

    So, what we did with ParkMyCloud, we actually manage the up time of those servers, so we only pay for the time we’re actually using those servers for our development for our staging.

    The other good thing we’re having is that we actually have quite good visibility. True—a nice supporting feature, which I think is pretty new, where we can see very, very quickly, you know, when is our load high, what is actually being used, what is not being used, if anything needs to shut down. So, we can manage that very, very easily. And specifically, on the park management, it’s almost a file and forget. Once you set it up once, you never need to go back to it, and it just does it for you.

    Shimel: Got it. So, Jonathan, let me just be clear, I want to make sure we’re talking apples to apples. So, when you say, you know, you’re not using the server overnight or something like that, are you saying that, with ParkMyCloud, you can schedule your instances to close? So, in other words, I’m only gonna use this instance from 9 to 5, and at 5:00, retire that instance, close it out, don’t keep it on my billing account, and when I start up again tomorrow at 9, I’ll start a new instance with that same configuration and kind of pick up where I left off, or is it something else?

    Chashper: So, first, we need to understand that you can use ParkMyCloud on your non-production instances. Production instances obviously need to be up 24/7, so you don’t want to shut them down.

    Shimel: Yeah, you’re right—I should have said that. [Laughter] No one wants to shut down their production.

    Chashper: Yes. So, what I was referring to, I was talking about our development and staging nonproduction systems.

    Shimel: Mm-hmm.

    Chashper: Yeah, so that’s for that.

    Shimel: But are you actually—I guess what I’m asking, are you retiring those instances and firing up new ones the next day, or is it—

    Chashper: Oh, this is—yeah, so this is done automatically for us. That’s the beautiful thing about ParkMyCloud. We actually, once you set up the parking schedule, it will shut down the server, say, 5 p.m. today, and it will turn it on back tomorrow morning, say, 9 a.m. We don’t need to do anything. This is done for us automatically, and so you know, where the developers come back into the office, as far as they’re concerned, nothing changed, they just keep working.

    Shimel: That’s fantastic. Chris, I just want to confirm with you—those instances are actually, you know, it’s sort of like immutable infrastructure, right? Those instances are retired, done, and then re-fired up the next day?

    Parlette: Yeah, so what this is—and it’s not terminating the instances, it’s actually just stopping them and then turning the same ones back on. And the nice thing is about that, is that now, you know, as people are working on these servers, you know, if you haven’t fully gone with data, you know, not being stored on those servers, you know, as you’re working on these same servers over and over and over again, you know, we stop them and then start them right back up again. So, even if people like your finance department or your QA department maybe have some things, you know, spun up, we can actually turn them off to save on the CPU and memory costs, and then we just turn them back on again.

    Shimel: I got it. Okay, because I was gonna say, you know, I mean, the immutable infrastructure angle is great, but in this sort of circumstance, it’s not just a configuration of the server, it was the state of the data that you were working on, and how the heck would you re-create that every morning? [Laughter] But that explains it—got it.

    So, Jonathan, you know, so ParkMyCloud is making you guys a lot more efficient here in the cloud and your use of cloud resources. Have you been able to quantify a percentage savings or anything like that?

    Chashper: Oh, absolutely—most definitely. If I want to be, you know, conservative, I would probably say that we’re saving around 55 [percent]to 60 percent.

    Shimel: Really?

    Chashper: At least. Frankly, I think we probably save close to 70 percent. We’re really very tight. We really manage to do that in a very tight manner.

    Shimel: So, beyond just closing down and firing up the instances the next day, what are some of the other things you’re doing with ParkMyCloud?

    Chashper: Oh, so—well, for us, the first thing is reporting and notification. If something happens, we get notified, we can actually control what we get to be notified about. So, then we’ll get notification about maybe a server that needs to be shut down or something like that.

    Reporting is very important to us so you can see your usage, you can see what is up and what is down.

    Shimel: Got it.

    Chashper: One of the cool things we just started using is actually a mobile app. So, there is a mobile app on iOS for ParkMyCloud. People can download it at the iOS store. And it actually happened with me, I was at dinner, and we—my guys had to stay a little later, and we had to, what we call, snooze one of the parking, you know, schedules, and I just did that through the mobile app, I didn’t even have to go online.

    Shimel: Fantastic. Very cool. So, guys—look, 50 percent or better savings, all these other benefits is certainly nothing to sneeze at. I think anyone would jump at it.

    But, Chris, let’s dive in with you now a little bit, if we can. You know, we have an audience here of DevOps sort of folks from all over the world, right, who would love to save 50 percent on their cloud bill. How is ParkMyCloud working with these DevOps engineers and DevOps teams to realize those kinds of savings and efficiencies.

    Parlette: Sure, yeah. So, we work, you know, plug into a lot of DevOps processes and toolkits straightaway. I mean, that’s something that we do internally, and then, you know, we certainly have all of our customers, from large enterprises down to small startups, all doing this same kind of thing.

    And so, there’s a few different ways to do that. One of the big things about DevOps is automation, and so, we have a full policy engine so you can set up the policies to look at tags, to look at locations to different regions that these servers were in, naming schemes—all these different kind of factors, and you can automatically apply schedules and assign to teams and decide on different actions to take based on these policies for any new instances that you spun up. So, that’s one automated way.

    We also have a full API, so you could plug into DevOps tools like Atlassian, Bamboo or Jenkins so that these tools can kind of reach into our API, temporarily override schedules, change schedules—all this as a part of an automated thing.

    One of the other things about, you know, DevOps—not just automation, but also just thinking whole business, kind of a holistic approach to this thing—and so, we also have a full, a very easy to use UI. So, if your users are, maybe are a little less technical or you don’t want them to necessarily have direct access to a database console or Azure or Google consoles, this can kind of be sort of a proxy for that console so that other users can come in and manage their end servers. They don’t have to ask IT to turn things on for them. They can kinda manage their own servers and do all this, but you can decide who has access to what through this approach.

    So, there’s a couple different ways we plug into these teams and these processes so that users can get their best bang for their buck.

    Shimel: Got it, got it, got it. Now, so, Chris, when you talk about plugging into things like Bamboo or Jenkins, what you’re really—I mean, I just wanna make sure I’m clear. You can build sort of the ParkMyCloud—not sort of, but you can build the ParkMyCloud policies right into your CI/CD pipeline. Is that what you’re saying?

    Parlette: Yes, so if you do things like using tags, especially as instances are spun up or spun down, a lot of people say, you know, “Hey, I put a million tags on every instance.” And so, that’s what the ParkMyCloud policies can read off those tags and kinda decide on the actions based on those tags.

    And then, as far as things like—you know, specifically, if we were to talk about Jenkins or some other build processes, you know, you can have these environments built out and shut down. And then Jenkins, at the beginning of some sort of build process, can call into ParkMyCloud and say, “Hey, I need these servers up, and so I wanna override these schedules.” Spin ’em up, the servers are up, it does all it needs to do, and at the end, it just either shuts them down or, if you don’t shut them down, then basically, if you only did an override, let’s say, for two hours? At the end of the two hours, we’ll revert back to our original schedule, so that way you don’t have to remember to turn the lights out when you leave the room, right? So, we actually can shut things down for you.

    Shimel: Excellent. And Chris, give me an idea of—so, when you guys are engaged, I mean, with that kind of API, with that kind of integration into the DevOps toolset, you’re probably getting a decent view of how DevOps teams are using ParkMyCloud. And you’ve given us some examples, here.

    Are there any—I guess what I’m trying to ask, are there any special things that the DevOps people are doing that perhaps waterfall or other types of technologies are not doing? Is there commonality? Is it very easy to say, “Oh, these guys must be doing DevOps, because here’s, you know, what they’re doing?” Have you noticed any of that?

    Parlette: Yeah.

    Chashper: Alan, before Chris answers, maybe I can jump in and give a quick lead-in to this.

    Parlette: Sure.

    Chashper: Sorry, Chris—hope you don’t mind.

    Parlette: Sure.

    Chashper: Actually, one of the things I wanted to say is that we don’t have DevOps people at all, and one of the reasons we’re using ParkMyCloud is because we’re actually—we’re not DevOps people. We don’t know what needs to be done. We don’t speak, you know, Chef or any one of those guys.

    So—but the fact that we could actually use ParkMyCloud and then the user interface they provided us with, the web client, at least it did for us, went away, and everything is handled at that level. So, for us, that was a big, big move forward.

    Shimel: Yeah, no—and that actually is a great point, Jonathan. And Chris, I’m sorry we hijacked you here for a second.

    Parlette: No problem.

    Shimel: But the problem is, in today’s market, frankly, hiring people who have Chef or Puppet or Jenkins or, you know, DevOps skills sets is (a) hard to find, and (b) very expensive, right? And so, if you can deliver benefits like 50 percent savings on cloud usage or allowing some automation like this, it certainly is a lot easier. I don’t know of any engineering team that wouldn’t like that.

    But, you know, Chris, what do you see? I mean, are most of the people using the UI, or are they just you know, kinda going to APIs and stuff like that?

    Parlette: Yeah, and you know, as we get into larger customers, you know, it definitely is a mix of the UI and the API. The other change that we see, the mindset shift that we see from people is, especially as they’re moving from on-prem to cloud, a lot of people, when they’re used to—a lot of people, when they’re coming from a [Dog barks].

    Shimel: Hey, Jonathan, I think Chris might have shut off there for a second. Chris, you there?

    Parlette: Here we go. I’m back—I’m back. So, one of the things that, you know, as people are moving from on-prem to cloud, you get a lot of people who are used to leaving things on 24/7, because you know, on-prem, as things are left—you know, if you spin things up, it’s not an additional cost, really, to leave them on 24/7.

    And so, in this shift to the cloud, they have this shift of mindset where, if they’re being charged by the hour or it’s something that, you know, every hour that it’s left on is additional cost.

    Chashper: Yeah.

    Parlette: And so, when people are used to leaving things on 24/7, now the shift we have with people using ParkMyCloud, especially in an automated way, is to leave things off 24/7 and then kind of spin them up on demand. And so, that’s really where I think, you know, Jonathan and his team use that a lot, where things can be off, you know, turn on a schedule, but also just turn on on demand so, as the users have access to the UI and the API, they can turn things on on demand, as opposed to having to turn things off on demand.

    Shimel: Fantastic. Well, guys, you know, as I told you off mic, the time here goes really quick. [Laughter] We’ve already been on 18 minutes, beyond the 15 minutes I told you we would do, so we’re gonna need to wrap this one up right here. But first of all, Jonathan Chashper, CEO, Founder of WolfPack, it’s WolfPack.run is the URL, correct?

    Chashper: Yes, absolutely—thank you.

    Shimel: Thank you. Thank you for sharing with us today and giving us a little peek behind the kimono of how you guys are using ParkMyCloud. Continued success for any of our motorcycle riding friends or any group out there who—you know, I encourage you to check WolfPack out, it’s a pretty cool app.

    And Chris, thanks so much for sharing a little bit more, you know, a little behind-the-scenes look and a little bit more of a peek at, you know, ParkMyCloud and how it’s helping companies. Thanks for being on today’s DevOps Chat.

    Parlette: Yeah, Alan. Thanks for having me. I really appreciate it.

    Chashper: Alan—thank you very, very much. It was a pleasure.

    Shimel: Thank you, guys. You know what? We’re recording this right before Thanksgiving—have a happy holiday. Happy holidays to everyone listening! You’re probably listening to this after Thanksgiving, but it’s the start of the holiday season, so happy holidays, everyone.

    This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Hope to see you soon on another chat, and have a great day.

    — Alan Shimel