Tag: cloud-native

  • Distinguishing Between Cloud Washed and Cloud Native

    Distinguishing Between Cloud Washed and Cloud Native

    Don’t fall for the marketing jargon: Running legacy infrastructure on a cloud instance is not actually cloud computing. Unfortunately, “cloudwashing” is common among enterprises as they attempt to jump on the cloud trend.

    So, how do we dispel the hype to distinguish pure cloud software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS)? In this article, we’ll define cloud washed and cloud native, citing NIST standard definitions and industry expert opinions. We’ll add some cues to help decipher cloud washed versus cloud native architecture as you search for new tech. No whitewashing here; prepare for some hard truths.

    What is Cloud Washing?

    In recent years, services that simply work over the internet were rebranded with the “cloud” buzzword, perpetuating a tenuous, vague perception of the cloud.

    Cloudwashed solutions are legacy, on-premises software held in a virtualized data center and rebranded as cloud software. Such tools originally were not built for the cloud and do not satisfy the NIST definition of true cloud computing.

    While non-local hosting can reduce maintenance and server costs, by adopting cloudwashed services you sacrifice the benefits of cloud native. As Clint Boulton, writing for CIO describes:

    “… the implementation doesn’t provide automated, continuous upgrades, let alone the multitenancy, self-service, auto-scaling and usage-metering capabilities that have come to characterize cloud services …”

    Cloud Native: What is True Cloud Computing?

    Cloudwashed is diametrically opposed with cloud native. To understand the true native cloud, let’s turn to the NIST official definition of cloud computing:

    “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

    NIST also defines three service models of cloud computing (SaaS, PaaS and IaaS), and specifies four types of deployment models (private, community, public and hybrid).

    As you can see, the NIST definition of cloud computing is specific. Authentic cloud services are configurable, providing hands-on optimization. They are elastic, able to provision and support multiple application requirements. Such cloud architectures are able to efficiently scale to the unique computing workloads of various applications.

    Furthermore, resources for cloud services are pooled. According to HiTechNectar, “True cloud platforms are built on a true multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.”

    A cloud-native application (NCA) is thus an application specifically designed for the cloud that satisfies the definition of cloud computing. A true cloud solution would be a proprietary service built on a platform such as CloudStack or OpenStack. Google Cloud, Amazon Web Services and Microsoft Azure are all examples of authentic cloud providers.

    Cloudwashing Warning Signs

    Cloudwashing is rampant in the ERP realm. As HiTechNectar reports, “Many enterprise software vendors make claims that their applications are built for the cloud when they are not.”

    Thus, to avoid cloudwashed software, take heed of these warning signs:

    • Overuse of “cloud” in vague marketing jargon.
    • The need for custom integrations (this is against self-service).
    • No resource pooling.
    • Lack of developer tooling.
    • Lack of configurability.
    • Tooling not planned with redundancy in mind.
    • Server arrangement is not distributed.

    Good Signs of a True Cloud

    Thankfully, finding true cloud computing is made possible with the help from NIST, which lists five essential elements of cloud computing:

    • On-demand self-service.
    • Broad network access.
    • Resource pooling.
    • Rapid elasticity or expansion.
    • Measured service.

    Another good sign is the vendor’s involvement in the Cloud Native Foundation. Companies also dedicated to open source projects tend to be more progressive and transparent.

    Dissipating the Foggy Cloud

    A recent CompTIA Report found that half of the companies in 2018 have 31 percent to 60 percent of their IT systems in the cloud. Cloud computing is still driving the rise of cutting-edge trends including AI, blockchain and IoT.

    Unfortunately, though, not all purported cloud services are authentic. Ruled by an incessant need to stay relevant, tech marketing adopts and overuses certain jargon, and the “cloud” is not immune. Only by understanding the dichotomy between cloud washed and cloud computing can CIOs make educated decisions regarding their tooling choices.

    The NIST cloud computing criteria is valuable because NIST is an impartial standards agency. NIST computer scientist Peter Mell stresses the importance of evaporating this fog to reveal the truth:

    “… by adopting an authentic cloud, [businesses] are more likely to reap the promised benefits of cloud—cost savings, energy savings, rapid deployment and customer empowerment.”

    To avoid being cloudwashed, seek out multi-tenant architectures with self-provisioning, pay-per-use models, virtual instances and linear scalability. Only then will you reap the rewards of an authentic cloud-native environment.

    — Bill Doerrfeld

  • Twistlock Releases Cloud Discovery Open Source Tool for Cloud Native Services

    A simple, powerful way for audit and security practitioners to discover all ‘unknown unknowns’ across cloud environments

    PORTLAND, Ore., Nov. 13, 2018 /PRNewswire/ — Twistlock, the leader in container and cloud native cyber security, today announced the release of the open source Cloud Discovery tool. Cloud Discovery gives enterprise infrastructure, operations, and security teams the ability to easily understand and quantify the size of their environment, and get a birds’ eye view of what cloud native services are running and where. The first release supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with more platforms to be announced.

    Cloud Discovery connects to cloud providers’ native platform APIs to discover services such as container registries, managed Kubernetes platforms, and serverless services, and requires only read permissions. Other key features include:

    • Network discovery to discover cloud native infrastructure and applications, such as Docker Registries and Kubernetes API servers
    • Instantly identify weak settings and authentication
    • Easily integrated into DevSecOps processes
    • Provided as a simple Docker container image that can be run anywhere and requires only read permissions to cloud accounts
    • Works well for both interactive use and automation
    • Outputs data into standard JSON for easy integration with other tools
    • Written in Go

    “In many organizations, IT ops, security, and audit personnel need to discover all the cloud native entities being used at their organizations,”  said John Morello, Chief Technology Officer, Twistlock. “This is often a result of development teams starting up resources and deploying cloud native applications, but the security or operations team may not always know exactly where they’re deploying them. We want to make that easy without creating any new security gaps.”

    “Since our founding, we’ve been committed to enhancing security efforts for the cloud native community through upstream contributions to open source projects,” said Ben Bernstein, Chief Executive Officer, Twistlock. “From creating the authorization framework within Docker and Openshift and secrets management for Docker Swarm, to the release of Cloud Discovery — open source is in our DNA. We hope Cloud Discovery helps the community and look forward to adding new features and components that benefit everyone.”

    View the Cloud Discovery repo (https://github.com/twistlock/cloud-discovery) on Github to get started or contribute to the project.  To learn more, visit Twistlock (https://www.twistlock.com/2018/11/13/open-source-cloud-discovery-tool/).

    About Twistlock
    Trusted by 25% of the Fortune 100, Twistlock is the most complete, automated, and scalable cloud native cybersecurity platform. From precise, actionable vulnerability management to automatically deployed runtime protection and firewalls, Twistlock protects applications across the development lifecycle and into production. Purpose built for containers, serverless, and other leading technologies, Twistlock gives developers the speed they want, and CISOs the control they need. For more information, please visit www.twistlock.com

  • DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

    DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

    Monitoring has come a long way since the days of 2 a.m. alerts, with automation and analytics now integrated in—and integral to—the life cycle of modern applications. It’s a topic Karthik Rau, CEO of SignalFx, knows well, and one we discuss in this latest DevOps Chat.

    In its three years of selling, SignalFx has grown a whopping 300 percent year over year—an astounding number, even for a startup.

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

    Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat features Karthik Rau, CEO of SignalFx. Karthik, welcome to DevOps Chat.

    Karthik Rau: Thanks, Alan. It’s great to talk to you again.

    Shimel: Always a pleasure to have you on. So, Karthik, let’s just do a little setting the base here, baseline setting. And I’m gonna assume most of our listeners have at least heard of SignalFx, but maybe some haven’t and maybe some have heard it but they’re not sure exactly of who SignalFx is. Why don’t we start there?

    Rau: Sure, Alan. SignalFx is a monitoring and operational intelligence solution for the developers and operators of cloud-native applications. Our founding team, my cofounder and our original engineering team, all came out of Facebook and were responsible for building the monitoring systems at Facebook, back when they had a “move fast and break things” culture, which today everyone calls DevOps, but, back then, they didn’t really have a term for it. So, at a high level, what we do different from everyone else is we are focused very heavily on the analytics part of the monitoring problem. We collect data – time series, telemetry data – across the customer’s entire environment, from the hardware to the middleware to the application, all the way up even through the API layer, and we apply real-time statistical models around that data to identify patterns that are unusual and different, and alert on those trends proactively so that customers can get ahead of issues and be more proactive in their monitoring, rather than reacting to a bunch of noisy alerts.

    So our customers are able to, No. 1, get a much better handle of their distributed cloud-native application architectures, understanding the patterns, what’s happening. They’re able to detect issues as they emerge, which is very important in today’s environments because most people are pushing changes out a lot more aggressively, and so you wanna detect changes immediately, rather than wait and discover stuff after you’ve made a number of changes. And it’s particularly important for today’s application architectures where you’ve got a lot of bursty workloads, like with containers, where you’re spinning up and spinning down capacity in minutes and you really need your monitoring systems to be (a) real-time and discover components immediately and then (b) be a lot more sophisticated in finding issues as they happen.

    Shimel: Excellent. And, Karthik, you know, I should also mention that, in terms of UI, SignalFx is one of the best UIs, web-based UIs that I’ve ever seen. And I’ve looked at a lot of applications, a lot of programs, over the year – over the years. Year? I wish it was “year.” And, you know, so – and I’ve told you this before. I’m just think whoever designs the interfaces there is a rockstar, so just mention that, but –

    Rau: Yeah. Thank you.

    Shimel: You know, we spoke a little bit off-mic, Karthik, and we were going over what are some of the new metrics coming out of SignalFx, how business is going, and you mentioned some really eye-popping numbers, right? First of all, you guys are showing something like 300 percent year-over-year growth for the last couple years, which is – you know, everyone will say, “It’s a startup; they’re supposed to grow like that,” but, dude, until you’ve done it, you haven’t done it, so that’s an astounding number. But also a big move into large enterprises. Is that correct?

    Rau: Yeah. So, yes, absolutely. So we’ve been, as you’ve mentioned, tripling our business year over year, since we – over the past year, but significant growth even above that in the early years. We’ve only been selling for about three years. Our customer base is focused quite a bit on mid- to larger-size companies, so we’ve always been focused on larger accounts, whether that’s the web-scale players, who are operating large-scale applications with four or five nines availability requirements, but also a lot of the enterprise accounts, who what we’ve been really excited about is they’re really moved wholesale into cloud and cloud-native application architectures. And we’ve seen that trend accelerate over the last two or three years, so that’s been a large area of success for us. You know, we’ve got Fortune 500 customers across many verticals – media, retail, financial services, industrials, transportation – so we’re definitely seeing that trend accelerate across the enterprise, not just in a handful of verticals.

    Shimel: Absolutely. But, Karthik, what about for the person out here listening to this, right? And he says, “Wow, that sounds great. I love what Karthik says they’re doing and the Facebook kinda background and all of this great stuff, but I’m not a unicorn. I’m not even a large enterprise.”

    Rau: Well, I think that everyone today is trying to build software quickly, right? Gone are the days where you have a three-year development cycle and you release software and hope you get it right. It’s just not gonna work in today’s world of web services and your competition are tech companies that are moving at lightning speed. So the issue isn’t really – the world is changing. The way people are building and releasing and managing software is fundamentally different.

    And what SignalFx does, the analytics around SignalFx, you can look at it in two ways. One way is, yes, if you’re a large environment, you absolutely have to have it to reduce noise, but another way of looking at it is you could be a small environment and you wanna have a more predictive way of discovering issues, as they emerge, so that you too can move fast without breaking things, right?

    And if you look at it that way, having the kinds of capabilities that SignalFx provides are critical, even if you’re a department within a big company or you’re a startup with 50 people or 20 people. You still wanna be able to do the proactive analysis of, “Hey, this code push that I just rolled out, a canary release, is unusual relative to the rest of my application. And maybe that’s indicative of a problem with my code and I wanna roll it back before rolling it out across all of my users.” Right? You don’t have to be Facebook-sized or Google-sized to have that problem. You’re just building a modern application.

    So that’s why we do have customers across segments. I mean, our focus is certainly on the larger accounts, but we’ve got a lot of departmental deals within enterprises. We’ve got a lot of startups that are also using us, who care about having a more predictive approach to monitoring.

    Shimel: Yeah, no, you know, I think the key there – and you mentioned the word, Karthik, and it’s funny; it’s a word I’ve been hearing over and over again. And that this term of the “modern application.” I don’t care whether you’re big, small or Goldilocks. The modern application, as we call it, right, demands certain things, and one of them is obviously monitoring, but also modern applications demand automation, real-time type of data flows and insight. And it’s not just the guys who develop once every few years – that certainly is not a modern application – but it’s also more than just how frequently you update your code. I think the modern application, you know, what goes are in, the kind of stuff, or at least one element of it is the kind of stuff you’re talking about with SignalFx. Right? These go like hand in glove.

    Rau: Yeah. Absolutely.

    Shimel: So I think that’s – so, to me, more than size of company. I mean, that’s almost a determining factor. Another item I just wanted to mention on the – or bring up on SignalFx itself, as a company, is you guys recently announced a rather large round of funding as well.

    Rau: That’s right, Alan. On the backs of all of our success, we continue to build out our product and continue to accelerate our go to market. We just closed a $45-million Series D round in May and we’ll be using that to continue our investment in R&D. We’re continuing to expand globally. I think I’d mentioned to you offline here that we’ve just expanded into Europe. We also recently expanded into Australia. We’ll continue our expansion geographically, so, hopefully, a lot more people across the seas will hear about us and see us, in the coming quarters.

    Shimel: No doubt in my mind about it, Karthik. I can tell you, from – when I look at devopsy.kinsta.cloud’s demographics and metrics and analytics, it blows me away that only about 36, 35 percent of our audience these days are U.S.-based.

    Rau: Mm-hmm.

    Shimel: About 31, 32 are based in Europe. 15 percent in India. Australia is probably the fourth or fifth largest country, for instance, for our readers. So –

    Rau: Yeah, that’s right.

    Shimel: – you know, the thing about this market is it’s truly, truly a worldwide market. And I know, Karthik, if you’ve had the chance to go to China recently, but I was there for Interop China last month, talking about DevSecOps, and I will tell you that the DevOps market in China is exploding. I mean, just there’s a lot of people there, obviously, as there are in India, but DevOps is really catching fire.

    And, as you and I were talking about offline, Karthik, it’s one thing if you’re chasing that crowd or you’re chasing that wave. In the case of SignalFx, it’s a beautiful thing, where, maybe when you did launch, you were a little out ahead of the market, a little out ahead of the state of art, but they’re catching up to you now, right? They’re coming. And it’s good to be there, waiting for them.

    Rau: Yeah, absolutely. The market – what’s been most interesting about – you know, at SignalFx the last several years, has been, when we launched the company three years ago, our – what we did that was so different from everyone else is we had this real-time streaming analysis engine, streaming analytics engine, that could apply these sophisticated models within seconds across large data sets and help you be a lot more predictive in identifying issues. And no one else was doing it that way and still no one else is doing it that way. And, at the time, people would ask us questions of like, “Well, what does it really matter if you can do things in seconds versus minutes? ‘Cause the human attention span is only minutes and if you wake up in the middle of the night, it might take you minutes to go and deal with an alert.”

    Well, that was kind of in the old days. Now what’s happening is there’s so much more automation happening across the entire operations landscape. I mean, people talk about it as infrastructure as code, right? You basically automate the entire end-to-end process as much as you can. And, more and more, there are these frameworks that enable greater automation, like Kubernetes, and what we’re finding now is people are really recognizing that, “Maybe we don’t need roomfuls of NAC engineers waiting to find a yellow light or a red light to then go and manually invoke a script from a run book, if we can just automate it.”

    Well, guess what? If you’re gonna automate a remediation like that, garbage in, garbage out. You need quality in. You need to have quality signals. You need to be able to untease signal from noise and you need to be able to do it quickly. And if you can do it quickly, then you can automate quickly and you don’t – the whole notion of having a human wake up and spend minutes orienting themselves goes out the door ’cause you can just – or having the roomful of NAC people responding to it goes out the door. You can just automate it. And then the capabilities of SignalFx then are very unique and very critical to enabling you to drive this end-to-end automation.

    And what we’re finding is now more and more of our customers and marketplaces recognizing this, as they’re embarking down this path of leveraging microservices and automation around microservices and infrastructure as code. Having a system like SignalFx, with its real-time analytics, is absolutely critical. So it’s been fascinating to see that evolve over the last few years.

    Shimel: Yeah. No, for sure. You know, Karthik, it was interesting. I saw an interesting metric today. Something – I forgot who it came out of – Gartner or someone. Within two years, something like two-thirds of cloud deployments will be container-based, which kinda blew me away, to tell you the truth. Have you heard anything like that?

    Rau: I mean, that’s an incredible metric. I mean, I would say we’re certainly seeing a tremendous amount of interest in containers. Well, it’s gone from interest to actual deployments, right? So, two years ago, there was a tremendous amount of interest in it. Nowadays, I would say that is the de facto new architecture, so I think the keyword there is “new,” right? So two-thirds of new deployments, I totally believe that, that that will be the case, 100 percent.

    Shimel: Crazy. I mean, we talk about internet time and the time crunch and it seems to be accelerating like global warming is and climate change is, but the idea that we’d see that kind of number in that kind of time just kinda blows me away. So, Karthik, we spent a bunch of time with this stuff, going over the SignalFx, a little bit about the market, right? Let’s take a look at a crystal ball and gaze into where do you see SignalFx, let’s say, going over the next, let’s say, 18 tp 24 months?

    Rau: Well, we continue to invest across our business, right? So our focus right now is we believe there’s a giant problem that needs to be solved in the industry, which is, “How do you get better visibility and monitoring around the new stack? And then, beyond that, how do you get better visibility into how your operations are impacting your business?” So, as I mentioned at the top of this podcast, we think of ourselves as monitoring and operational intelligence for modern applications, so one of the things that we – we see all our customers go through a similar progression, where you’ll start doing the infrastructure monitoring for this new world, where you gotta look at the entire microservice, versus an individual node, and you start to get into application and look at application performance issues.

    But then, very quickly, customers typically start to look at how are all of these metrics affecting their business, right? You know, “How many of my partners are making API calls in my services? And who are my most expensive partners and my least expensive partners?” Or, if you’re a SaaS vendor and you wanted to do a gross-margin analysis by customer, all of the data already exists in your monitoring system, and we see more and more of our customers extending the use of these systems to answer broader questions around operational intelligence.

    So that’s kind of – those are the three sort of key pillars of what you use a system like a SignalFx for, right? It’s infrastructure monitoring, it’s application monitoring, and then it’s operational intelligence. So our plans, as a company, are really focused around those three pillars. You need to invest in product to support all of the use cases around those three areas. And then continuing to invest in our sales and marketing team so that more and more companies out there can benefit from what we have to offer. So that’s our focus over the next 18 to 24 months.

    Shimel: Fantastic. And, as we spoke about earlier, it’s nice to be out in front of the market, but, Karthik, your job, as the CEO, if you choose to accept this mission impossible, is how do you stay out front of it? You’re right? How do you know – how do you – I mean, you think containers are gonna be dominant, right, so you wanna put that cloud-native dominant. What do you think is sort of next big things coming out there?

    Rau: Well, in our space, I think the most fascinating new set of technology is around service mesh. You know, as more and more of the world moves toward leveraging containers and orchestration frameworks like Kubernetes, the service mesh is gonna be a really interesting way of automatically getting visibility into all of the flows between all of these different microservices, having a control plane to operate against all these microservices. And it’s still relatively young. It’s still in its infancy, but there’s a lot of great stuff happening there, you know, what you see Lyft doing with Envoy and Istio and LinkerD. There’s just a lot of really interesting stuff happening there.

    And the theme here is, as developers own more and more of running their applications and the runtime, what you’ll find is more and more of the stuff that used to be this black-box, proprietary thing that vendors would come in and do in the runtime are just becoming available as a part of the core services. So, in the case of service mesh, a lot of the instrumentation of metrics and traces and monitoring data is just you’re gonna be able to get it by virtue of running in a Kubernetes-style environment and you’re not gonna need these expensive, proprietary agents to come in and collect that data for you.

    So that’s great for customers. It creates a standardized mechanism of data collection and it provides a lot of automatic instrumentation, which is great for customers. Of course, then that just begs the next question, “Well, what are you gonna do with all that data?” So we’re focused on ingesting more and more of these new types of data from these new frameworks and making it even more – the more data we get, the more powerful and rich the context we can provide around our alerts and algorithms and dashboards, so we’re really excited to see that trend continue.

    Shimel: Very cool. Karthik, we’re about out of time. We’re probably over time here. I apologize for keeping you on so long. But, hey, man, you guys are kicking butt and taking names, and congratulations. For anyone listening out there who hears Karthik talk about growing 300 percent at SignalFx year over year and raising $45 million and it sounds like, “Well, la dee dah,” I’ve been there and I can tell you it’s not easy. So congratulations. Keep up the great work and we’d love to check back in –

    Rau: Thank you, Alan.

    Shimel: Let’s not wait a year to check back in with SignalFx. Let’s have you on here sooner than later.

    Rau: Absolutely. Let’s do it again soon, Alan. Sounds good.

    Shimel: Karthik Rau, CEO, cofounder of SignalFx, our guest here on DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • How DevOps Can Create Smarter, More Agile 5G Telecom Networks

    How DevOps Can Create Smarter, More Agile 5G Telecom Networks

    There is no doubt DevOps revolutionized software development with its introduction of lean and agile techniques. By applying continuous deployment and continuous integration methodologies into software development, enterprises can build, test and deploy applications and release new services more rapidly. In this article, we will see how the DevOps approach is being utilized in 5G telecom networks with the rise of software-defined systems.

    Emergence of Software in Legacy Telecom Networks

    In last few decades software has changed our lives in myriad ways—mostly for the better. Now, software is starting to disrupt the telecommunication industry with the eagerly anticipated 5th generation of telecom network, also known as 5G. It is expected to provide low latency and high bandwidth network connections to serve use cases including artificial intelligence, smart city, 3D video, industry automation and self-driving cars, and to provide end-to-end real-time experiences such as virtual reality and augmented reality. A variety of these use cases have different network requirements and dependencies, and 5G is expected to provide such flexibility along with agility.

    Software-defined networking (SDN) and network functions virtualization (NFV) form the backbone of the upcoming 5G network, enabling service providers to deliver lucrative services to their customers and realize a competitive advantage. SDN makes the network programmable and centrally controlled, while NFV replaces dedicated network appliances with software packaged in virtual machines on top of high-performance servers. SDN and NFV enables:

    • Better control over overall network.
    • Reduction of manual network configuration processes.
    • Lower CAPEX.
    • Network resiliency.
    • Orchestrate network dynamically.
    • Faster time to market, i.e. faster introduction of new services and features to customers.

    Application of SDN and NFV technologies in 5G telecom networks indicates the use of software in the legacy telecom network, wherein many network functions including firewall, content delivery network (CDN), network address translation (NAT), routers, deep packet inspection (DPI) and broadband remote access server (BRAS) can be virtualized and serve as virtual network functions (VNFs) in NFV architecture. This stands as the core feature of upcoming 5G networks, as most of hardware-dependent operations will be performed by software, providing higher performance with tons of benefits to end users.

    Cloud-Native Enables DevOps

    Virtual network functions (VNFs) are the software representation of network function appliances in NFV environment and a core element in 5G networks. Services can be provided by chaining different VNFs developed by different vendors. There are complexities associated with having multivendor VNFs, as each VNF has its own performance and operational issues including manual integration in NFV infrastructure, utilization of NFV hardware resources, lack of interoperability and multitenancy. For a 5G network to deploy successfully, each VNF must be configured and managed in automated way.

    As software becomes part of telecom network, the term “cloud native” becomes part of the vernacular for VNFs.

    By harnessing a cloud-native approach—including containerization, microservices-based architecture and dynamic orchestration—VNFs with their own life cycle enable:

    • Decomposition of sub processes into microservices—resources required will be automatically scaled and communicated with other services using APIs.
    • Management and simplified orchestration of VNFs.
    • Deployment within containers and connected by APIs.
    • Orchestration by container scheduler—manages provision into service and lifecycle management.
    • Portability to different NFV environments.

    More importantly, a cloud-native approach allows VNF vendors and service providers to impose DevOps (continuous deployment and integration) methods to automate process of building, validating and deploying VNFs into NFV environments.

    A DevOps approach in 5G networks brings benefits for overall network operations, enabling deployment automation and management of service chains and 5G network slices. Complete automation is required, especially for 5G network operations, which may increase operational efficiency and decrease human error, saving OPEX and decreasing expensive downtime.

    For 5G networks, requirement of DevOps methods in VNF can be for:

    • Automated onboarding and deployment of VNFs in NFV environment.
    • Automated performance testing and benchmarking for VNFs.
    • Enabling self-scaling of VNFs—automated resource provisioning for VNFs.
    • Rnabling self-healing after an error in VNFs residing in VMs or containers.
    • Real-time monitoring of VNF activities for analysis.

    More ‘Intelligent’ Network

    Cloud-native capabilities and a DevOps approach opens the possibility of incorporating artificial intelligence in 5G telecom network operations analysis and real-time monitoring. Cisco Systems has already introduced its solution based on machine learning, which it calls Intent Based Networking. We can imagine a network operation having “zero touch” feature by just providing an intent to complete network for any configuration or specific network-based instruction. The collected analysis data can be used in the management and organization of NFV for corrections of network errors, adjustments in VNF and NFV elements configuration and self-healing/scaling of network functions.

    Summary

    Development of 5G network is still in process. By taking into account a revolution in SDN, NFV, cloud native and DevOps, it is expected that we will have 5G networks by some of leading players Verizon, AT&T, Telefonica and Vodafone reasonably soon.

    — Sagar Nangare

  • NATS Messaging Entering Cloud Native Purview

    NATS Messaging Entering Cloud Native Purview

    The Cloud Native Computing Foundation (CNCF) has expanded the scope of its purview by adding open source NATS messaging software to an expanding list of technologies it now oversees.

    NATS messaging software has been commonly employed in environments such as platform-as-a-service (PaaS) environments. But with the rise of microservices, a campaign to make NATS a part of the portfolio of technologies that members of CNCF consortium will advance has begun in earnest, said Derek Collison, who lead the development of NATS and is now CEO of Synadia Communications, which is dedicated to enabling organizations to more easily deploy and manage messaging systems based on NATS.

    The ultimate goal, Collison said, is to not only make messaging ubiquitous, but also effectively invisible.

    Collison said he and the CNCF envision a world where messaging just comes baked into every application. PaaS environments may have driven mainstream adoption of NATS messaging to integrate various elements of an application, but microservices will make messaging a fundamental requirement for building applications that can efficiently scale, he said, adding too many organizations already run into these issues because they are depending on HTTP to integrate various microservices.

    NATS is already widely employed by a number of vendors and organizations including Apcera, Apporeto, Baidu, Bridgevine, Capital One, Clarifai, Cloud Foundry, Comcast, Ericsson, Faber, Fission, General Electric, Greta, HTC, Logimethods, Netlify, Pex, Pivotal, Platform9, Rapidloop, Samsung, Sendify, Sensay, StorageOS, VMware Acadiant, Weaveworks and Workiva.

    The core NATS server and NAT Streaming software are maintained by Synadia. There are clients for Python, Ruby, Node.js, Elixir, Java, NGINX, C and C#, as well as third-party contributions that add support for Arduino, Rust, Lua, PHP, Perl and others.

    Longer term, Collison sees NATS evolving to include functionality to support real-time applications, many of which today are using Apache Kafka software. Rather than having to deploy NATS and Kafka for different use cases, Collison said it will make more sense to have a common control plane to address multiple classes of use cases for messaging.

    Messaging systems in one form or another have been at the heart of integration platforms for decades now. But the assumption was always that integration would be addressed after the applications were deployed. In the future, the assumption is that all cloud-native applications need to be integrated, which is much easier to accomplish if they all come with some form of messaging capability baked in. Integrating and managing federated instances of messaging systems still will be required. But much of the lower-level functions now being centrally processed will be pushed out into the applications being integrated.

    Collison is the first to admit that messaging is not some new, emerging technology. But as microservices architectures continue, messaging will prove to be core to a new generation of cloud-native applications, he said. The CNCF is clearly betting that a consortium of vendors working on a common code base for messaging will accomplish that goal a whole lot sooner.

    — Mike Vizard

  • Microservices Days coming to a city near you

    Microservices Days coming to a city near you

    Microservices is rapidly becoming a design paradigm for developing software. While there are many benefits to microservices designs, it is more complex than traditional application design. For this reason we are formulating a new community around microservices architecture. This community will explore design issues and the intersection with Mobile/IoT, Containers, Cloud, DevOps and APIs.

    Microservices Journal is a newly-launched online community where practitioners can share their experiences and learn from others.

    Microservices Days are a series of regionally delivered one-day seminars led by practitioners.

    Who should attend: CIO/CTO, Application Development Management, Software Engineers, DevSecOps, and IT Operations.

    For our 11/16 program we are lucky to have some strong industry experienced speakers come speak:
    • Michael Cote – Pivotal
    • JP Morgenthal – DXC.technology
    • Deepak Kulkarni – Charles Schwab & Co
    • Irakli Nadarishvilli and Mark Donovan – CapitalOne
    • Ryan Bagnulo – Guarden.io

    This is a great opportunity to come hear from early adopters and learn from their experiences.

    Register Now: http://www.innotechconferences.com/austin/about-2/microservices-day/

    Microservices Days, Austin – Agenda

    Time Presentation 
    8:00am
    9:30am – 10:15am
    10:20am – 11:05am
    jpmorgenthal
    11:10am – 12:00pm Deepak_Kulkarni

    12 Factors for the Enterprise

    12:00pm – 1:00pm Lunch and Expo
    1:00pm – 1:45pm Microservices_Irakli_MarkImplementing Microservices at Capital One
    2:30pm – 3:20pm TBA
    3:30pm – 4:20pm RyanBagnulo
    Microservices Maturity Matrix, Token Authentication & API Gateway Mediation

     Register Now: http://www.innotechconferences.com/austin/about-2/microservices-day/

    — JP Morgenthal

  • SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    This post supports my DevOpsDays Austin Presentation on May 4

    I don’t believe in DevOps shaming. Our community seems compelled to correct use of DevOps as an adjective for tools, teams and teapots. The frustration is reasonable: DevOps clearly taps into head space for both devs and operators who see a brighter automated future together. For example, check out this excellent DevOps discourse by Cindy Sridharan.

    As an industry, we crave artificial conflict so it’s natural to try and distill site reliability engineering (SRE), DevOps and cloud native into warring factions when they are not. They all share a focus on Lean process.

    Very simply: SRE is a job function, DevOps is a process approach and Cloud Native is an architecture.

    These three concepts have tremendous alignment because they all have the same fundamental goal: increase product delivery through improved flow. It’s really that simple. We are looking to enhance productivity using system thinking concepts from Lean manufacturing.

    SREs improve productivity by eliminating manual operations, reducing errors and improving infrastructure quality. They do this starting from the production infrastructure and working backwards. Highly automated delivery, integrated logs, systemwide monitoring and blameless root cause analysis are key tools. Before we get wrapped up in tools, the distinguishing factor for SRE teams is that they take ownership of the production infrastructure.

    There is tremendous power in assigning ownership for delivery. That’s why I see industry benefit in defining an SRE job function. A DevOps strategy is a system approach and it becomes an anti-pattern to making an individual or team responsible to own “the DevOps.”

    In DevOps, we look for ways to streamline the entire product creation flow. That often drives toward tools and techniques that SREs require; however, our goals are not department-specific. We want to work with all stakeholders including developers, product managers, testers, SREs, executives and customers. This system focus for developers becomes CI/CD pipelines, platforms, work tracking tools and other workflow elements. These tools are not specifically DevOps tools, but confusion is natural since they are often pulled into organizations due to DevOps thinking.

    This SREs should expect to collaborate deeply with other functions under a DevOps process.

    Cloud-native architecture also falls under the DevOps mandate because it strives to decompose large application stacks into highly automated collections of services. There is no magic “DevOps platform” in cloud-native design; however, teams using the architectural approach get modularity, strong APIs, service orientation, simplified configuration and build automation practices that fit perfectly into DevOps thinking.

    For example, using containers does not mean a dev or SRE team is following DevOps process or using cloud-native architecture; however, it is an indicator that they are leaning toward smaller deliverables and improved dev-production fidelity.

    Yet, SRE, Cloud Native and DevOps do have a shared enemy: Complexity.

    We’re doing a great job creating best practices and abstractions that accelerate developers and creating innovative infrastructure options in both cloud and physical. That means we are seeing dual explosions in developer productivity and infrastructure complexity. Unfortunately, this wealth has not made it into operations automation, which has been delivering incremental improvements at best. Even worse, the added workload and complexity adds pressure to SRE functions.

    Ultimately, all three of these concepts are aspects of Lean business practices; however, acceleration from DevOps and cloud native is outpacing progress by SREs. This imbalance creates risk for everyone involved because Lean is about system performance. Delays and failures cannot be isolated to a single silo.

    The mistake of seeing Dev and Ops as silos means creating false contention between SRE, DevOps and cloud native.

    If you are hearing that in your organization, then take it as a warning about how your teams are integrating Lean systems thinking into your processes.

     

    — Rob Hirschfeld

  • Should Your Apps be Cloud-Native?

    Should Your Apps be Cloud-Native?

    There’s plenty of life left in a great number of the applications companies have been relying on and profiting from for years. The future may belong to cloud-native apps that deliver the performance and efficiency benefits of microservices and containers, but in the here and now, organizations are looking for ways to combine the best of the old with the promise of the new.

    With continuous development, you could argue that the software industry has eliminated the concept of product life cycle altogether. Yet, IT managers know that some of the applications currently used by their organization likely will be running long after they have hung up their compilers.

    These legacy applications have proven their worth many times over. Some are one-offs that easily accommodate and are accommodated by new systems as they are implemented. Some are so good at what they do they epitomize, “If it ain’t broke, don’t fix it.” In the mass migration of apps and data to the cloud, it’s natural that such grand old apps would come under scrutiny as candidates for replacement by their cloud-native counterparts.

    In a Dec. 8, 2015, article on The Stack, Red Hat’s Gordon Haff examined the results of a recent IDC survey of enterprise DevOps teams, which found that 83 percent anticipate having to support legacy applications and infrastructure through 2019.

    DevOps_Cloud_Native

    It may seem counterintuitive, but the organizations that have gone furthest in adopting distributed, scale-out, microservices-based applications are twice as likely to delay converting existing apps to cloud architectures, he noted.

     

    What Characteristics Make an Application Cloud-Native?

    The simplest definition of a cloud-native application is one that is “decoupled from the physical infrastructure,” as TechTarget’s Sean M. Kerner wrote in a December 2015 article. In addition to being designed from the ground up to run in the cloud—whether private or public—the app also must scale on demand, both up and down, and across nodes.

    Cloud-native apps are fault-tolerant, built to scale and designed to process requests asynchronously, using queues to decouple functionality, according to Munish Kumar Gupta via Slideshare.

    Another feature that quickly is becoming standard on cloud-native apps is the use of Docker containers, which facilitates deployment on public Amazon Web Services (AWS) clouds and private OpenStack clouds, among other options. A more formal definition of “cloud native” likely will arrive soon from the Cloud Native Computing Foundation (CNCF), an effort sponsored by the Linux Foundation and others.

    Containers are a key component of the CNCF’s proposed standard for applications and services that run natively on public and private clouds, and that move seamlessly between the two environments. Rather than writing specs on paper first and then implementing the code based on the specs, CNCF will create the code for its reference implementations. Google, a CNCF member, has donated its Kubernetes container-orchestration system and stands to benefit via the foundation’s support for private and hybrid clouds, a technology the company currently lacks.

    The Continuing Evolution of Cloud-Native

    It’s tempting to limit the definition of a cloud-native app to those two primary characteristics: decoupled from the infrastructure and scalable up, down and across nodes. If this approach strikes you as too simplistic, you’re not alone. InformationWeek’s Charles Babcock explained in a July 30, 2015, article that the key to cloud-native is microservices—which he referred to as “discrete application services”—running in their own containers and connected via a network to create custom applications. The result is an environment for “user-driven systems” comprised of standardized parts and governed by “standardized deployment and operational procedures.”

    The combination of microservices and containers pushes down the app stack and simplifies deployment in computing environments of all types, according to Richard Harvey of Ngineered via SlideShare.

    The payoff for companies is still far off, according to Babcock, but ultimately cloud-native apps will keep firms focused on their customers as the software landscape shifts around them. This translates into a competitive advantage via continuous deployment and delivery of “fresh” software.

  • Alert Logic lends more agile, cloud-native security to DevOps architects

    Alert Logic lends more agile, cloud-native security to DevOps architects

    Amid the avalanche of research and product news emerging from this year’s Black Hat USA 2015 conference, held in Las Vegas this week, at least one vendor is attempting to advance a new solution aimed at empowering DevOps architects to streamline and improve security workflow.

    Houston-based Alert Logic announced the release of its Cloud Insight solution on Tuesday, positioning the offering as a cloud-native vulnerability and configuration management package designed for customers running on Amazon Web Services (AWS). Cloud Insight promises to integrate with AWS native security features, providing an integrated view of potential host and application-level vulnerabilities.

    By empowering operational teams, including DevOps architects, to identify and move to remediate vulnerabilities before affected applications code is pushed into production, company officials claim, the solution promises to both improve the configuration of resulting infrastructure and remove obstacles related to traditional cloud security management.

    “This solution is specifically aimed at helping AWS users who are not security professionals, such as operations and DevOps teams who deploy the infrastructure, address inherent security issues,” said Rahul Bakshi, Senior Director of Product Management at Alert Logic.

    “When you think of rolling security into the existing model, typically it interrupts the notion of continuous deployment, as historically it hasn’t integrated via the application or plugged into automated orchestration systems, becoming a hindrance,” Bakshi said. “That’s where this approach introduces a significant advantage, allowing organizations to identify and fix high risk vulnerabilities before the code gets pushed to production.”

    Unlike traditional vulnerability management specialists, such as Qualys or Tenable Network Security, which require users to manually configure and review data and provide only a “partial” view of cloud platforms such as AWS, Alert Logic claims that Cloud Insight lends critical automation to involved processes and allows ops teams to gain far deeper visibility into AWS services level security.

    Alert Logic has already won some customers over with its ability to enable greater control over applications security in the cloud. Speaking at the annual AWS Summit, held in San Francisco in April, Colin Bodell, Chief Technology Officer at publishing giant Time Inc., highlighted some of the work his company has done leveraging the vendor’s existing Security-as-a-Service offerings.

    “AWS is great for physical security, or for network security, but when you’re building an application you need to own security of the application yourself,” Bodell said. “AWS doesn’t know how you’re building things and you can build them in any weird and whacky way that you like; Alert Logic has been an amazing partner.”

    In the recent report, “Market Overview: Cloud Workload Security Management Solutions – Automate or Die”, published in June, analysts at Forrester Research highlighted the specific need for new security methodologies that integrate and automate processes to stem potential DevOps bottlenecks.

    “One of the key benefits of DevOps is to enable continuous integration of code and continuous delivery of apps and infrastructure,” the Forrester report notes. “To keep up, [security and risk management] pros must make security processes more embedded, faster, and more continuous – otherwise, security will slow down code release.”

    In terms of bringing Cloud Insight – which exists as a solution, rather than a SaaS service offering – to market, Alert Logic claims that it is successfully appealing to organizations’ hopes to embed AWS vulnerability management further within operations, despite introducing an altogether new and unfamiliar approach.

    “Beta customers seem very positive as we’re reducing the security workload and time related to remediation handoff for cloud architects,” Bakshi said. “There’s always a continuum for education, but with the culture of responsibility [for AWS security] evolving, we think that we’re meeting demand at just the right place.”

    Dan Raywood, Analyst at 451 Research, said that Alert Logic could take advantage of related demand by leveraging the combination of its existing cloud security expertise along with capabilities added via its January 2015 acquisition of Critical Watch.

    “I think it’s a very interesting move for them as even though they did have something offering this‎ type of scanning previously; the acquisition of Critical Watch added the engine to do continuous scanning and change management,” said Raywood. “The major bugs of the last year have driven business to assess and respond immediately, and having something which tells you if you are vulnerable or not a few clicks away is a really useful tool for businesses.”

    About the Author/ Matt Hines

    matthinesMatt Hines has over 18 years as an IT marketing/communications professional at companies ranging from ground-floor startups to established industry leaders with emphasis on advancing broader understanding of key technology industry trends, market drivers, customer requirements and innovative products to highlight value, increase awareness and drive revenue growth. Additionally Matt has a decade-plus writing in IT journalism covering leading trends for a wide array of industry-leading business technology publications including eWeek, InfoWorld, CNet and TechTarget. You can reach him on LinkedIn