Podcast – Haseeb Budhani on App Development for Edge and Cloud Best Fit

Posted on August 6, 2018 by spector13

Joining us this week is Haseeb Budhani, Co-Founder and CEO, Rafay Systems.

About Rafay Systems

Rafay Systems enables next generation performance improvements for SaaS applications delivered over the Internet. Rafay’s Programmable Edge™ platform equips developers with a disruptive set of tools to automatically deploy performance and geography sensitive applications, or micro-services, closer to endpoints. With presence at the infrastructure edge, Rafay’s platform enables organizations to deliver a new set of experiences to their end customers. For more information, visit https://www.rafay.co and join the conversation on Twitter @RafaySystemsInc.

Highlights

Building an application deployment platform as close to the Edge as possible
Supporting containers, microservices (move latency sensitive parts of app to Edge) and availability of infrastructure
Definition of Edge to Rafay Systems
Issues of massive amount of data at the Edge to be handled – Use Cases
Will Edge suffer from device specific infrastructure needs?
Application bottlenecks and impact of cloud locations and end user
Placement control of services is still an open issue based on user requirements
IT infrastructure and ownership and performance issues (IT vs Operation Teams)
Cloud and Edge are not competitive; they work together to offer applications best fit

Topic Time (Minutes.Seconds)

Introduction (and US Weather Update) 0.0 – 1.52
What is Rafay Systems trying to solve? 1.52 – 2.50
How does this fit in the world of containers? 2.50 – 4.40
What does Edge mean to you? 4.40 – 7.37
Issues of data at the Edge 7.37 – 12.52
Device specific vendors at Edge? 12.52 – 19.07
Recognize where application bottlenecks are 19.07 – 24.30
Placement of apps using Rafay Systems platform 24.30 – 28.25
Comcast as your data center 28.25 – 28.53
IT infrastructure and ownership 28.53 – 33.45
Closing thought from Haseeb 33.45 – 35.48
Wrap Up 35.48 – END

Podcast Guest: Haseeb Budhani, Co-Founder and CEO, Rafay Systems

Haseeb Budhani is the CEO of Rafay Systems, which he co-founded in late 2016. Prior to Rafay, Haseeb spent a year at Akamai Technologies as the company’s Vice President of Enterprise Strategy. Akamai acquired Haseeb’s previous company, Soha Systems, in October 2016. Haseeb co-founded Soha in the second half of 2013 and served as the company’s CEO. Prior to Soha, Haseeb served as the Chief Product Officer for Infineta Systems, where he was responsible for overseeing all aspects of the company’s product marketing, marketing communications and partner management activities. Prior to Infineta, Haseeb served as Vice President for NET’s Broadband Technology Group, spearheading the group’s product marketing, program management and business development functions. Previously, Haseeb held senior product management, marketing and engineering roles at Personal IT, Citrix Systems, Orbital Data, IP Infusion and Oblix. Haseeb holds an MBA from UC Berkeley’s Haas School of Business and a B.S. in Computer Science from the University of Southern California.

DC2020: Putting the Data back in the Data Center

Posted on April 18, 2018 by Rob H

For the past two decades, data centers have been more about compute than data, but the machine learning and IoT revolutions are changing that focus for the 2020 Data Center (aka DC2020). My experience at IBM Think 2018 suggests that we should be challenging our compute centric view of a data center; instead, we should be considering the flow and processing of data. Since data is not localized, that reinforces our concept of DC2020 as a distributed and integrated environment.

We have defined data centers by the compute infrastructure stored there. Cloud (especially equated with virtualized machines) has been an infrastructure as a service (IaaS) story. Even big data “lakes” are primary compute clusters with distributed storage. This model dominates because data sources locked in application silos control of the compute translates directly to control of the data.

What if control of data is being decoupled from applications? Data is becoming it’s own thing with new technologies like machine learning, IoT, blockchain and other distributed sourcing.

In a data centric model, we are more concerned with movement and access to data than building applications to control it. Think of event driven (serverless) and microservice platforms that effectively operate on data-in-flight. It will become impossible to actually know all the ways that data is manipulated as function as a service progresses because there are no longer boundaries for applications.

This data-centric, distributed architecture model will be even more pronounced as processing moves out of data centers and into the edge. IT infrastructure at the edge will be used for handling latency critical data and aggregating data for centralization. These operations will not look like traditional application stacks: they will be data processing microservices and functions.

This data centric approach relegates infrastructure services to a subordinate role. We should not care about servers or machines except as they support platforms driving data flows.

I am not abandoning making infrastructure simple and easy – we need to do that more than ever! However, it’s easy to underestimate the coming transformation of application architectures based on advanced data processing and sharing technologies. The amount and sources of data have already grown beyond human comprehension because we still think of applications in a client-server mindset.

We’re only at the start of really embedding connected sensors and devices into our environment. As devices from many sources and vendors proliferate, they also need to coordinate. That means we’re reaching a point where devices will start talking to each other locally instead of via our centralized systems. It’s part of the coming data avalanche.

Current management systems will not survive explosive growth. We’re entering a phase where control and management paradigms cannot keep up.

As an industry, we are rethinking management automation from declarative (“start this”) to intent (“maintain this”) focused systems. This is the simplest way to express the difference between OpenStack and Kubernetes. That change is required to create autonomous infrastructure designs; however, it also means that we need to change our thinking about infrastructure as something that follows data instead of leads it.

That’s exactly what RackN has solved with Digital Rebar Provision. Deeply composable, simple APIs and extensible workflows are an essential component for integrated automation in DC2020 to put the data back in data center.

Podcast – Oliver Gould on Service Mesh, Containers, and Edge

Posted on March 19, 2018 by spector13

Joining us this week is Oliver Gould, CTO Buoyant who provides a service mesh abstraction view to micro-services and Kubernetes. Oliver and Rob also take a look at how applications are managed at the edge and highlights the future roadmap for Conduit.

Highlights

Defining microservices and Kubernetes from Buoyant viewpoint
Service mesh abstractions at a request level (load balance, get, put, …)
Conduit overview – client-side load balancing
Service mesh tool comparisons
Edge Computing discussion from service mesh view

Topic Time (Minutes.Seconds)

Introduction                                                                0.0 – 1:39
Define Microservices 1:39 – 5.25
Define Kubernetes 5.25 – 10.23 (Memory as a Service)
Service Mesh Abstractions 10.23 – 12.37 (L5 or L7)
Conduit Overview                                                      12.37 – 18.20 (Sidecar Container)
When do I need Service Mesh? 18.20 – 19.55 (Complex Debugging)
Service Mesh Comparisons 19.55 – 22.31
Deployment Times / V2 to 3 for DRP 22.31 – 25.13 (Kubernetes into Production)
Edge Computing 25.13 – 27.04 (Define)
App in Cloud + Edge Device? 27.04 – 31.10 (POP = Point of Prescience)
Containers + Serverless 31.10 – 34.30 (Proxy in Browser)
Future Roadmap 34.30 – 37.06 (Conduit.io)
Wrap Up                                                                    37.06 – END

Podcast Guest: Oliver Gould, CTO Buoyant

Oliver Gould is the CTO of Buoyant, where he leads open source development efforts. Previously, he was a staff infrastructure engineer at Twitter, where he was the tech lead of the Observability, Traffic, and Configuration and Coordination teams. Oliver is the creator of linkerd and a core contributor to Finagle, the high-volume RPC library used at Twitter, Pinterest, SoundCloud, and many other companies.

June 16 – Weekly Recap of All Things Site Reliability Engineering (SRE)

Posted on June 16, 2017 by Rob H

Welcome to the weekly post of the RackN blog recap of all things SRE. If you have any ideas for this recap or would like to include content please contact us at info@rackn.com or tweet Rob (@zehicle) or RackN (@rack ngo)

SRE Items of the Week

The Cloudcast #301 – SRE and Infrastructure Operations
http://www.thecloudcast.net/2017/06/the-cloudcast-301-sre-and.html

Description: Brian talks with Rob Hirschfeld (@zehicle, Founder/CEO of @RackN) about the concepts of SRE (Site Reliability Engineering), the challenges of maintaining infrastructure software, emerging tools and the next-generation of operations.

Show Notes:

Topic 1 – Welcome back to the show. Let’s start by talking about the concept of SRE (Site Reliability Engineering). Give us the basics and maybe explain how it differs from what people define in DevOps.

Topic 2 – Application development has been moving faster for quite a while (agile development, etc.). But now infrastructure/operations teams have to deal with faster software – especially around updates (e.g. Kubernetes releases every 3 months). How are companies managing this?

Topic 3 – Given that this pace of operations change may not slow down, how do you think about the challenge in terms of process/operations versus technology/tools?

Topic 4 – What are some of the steps that companies take to better prepare for this type of operational model? Tools, process, skills, etc.

Topic 5 – Do you see SRE as being a progression for existing infrastructure/operations people, or is this more focused on sysadmins or developers that want to get away from building applications?

_____________

DevOps Enterprise Summit London: Tales of courage and community
https://techbeacon.com/devops-enterprise-summit-london-tales-courage-community

After spending two amazing days with 700 of my closest DevOps cohorts from Europe, the Middle East, Africa, and beyond, I learned all about the latest and greatest IT and technology transformation reports at the DevOps Enterprise Summit London. With substantial growth in attendance from the first year, in 2016, the buzz around the show was palpable. And, what a location! From the venue, the QEII Centre, we had 360-degree views of central London, from Big Ben to the London Eye and beyond.

Read more from Steve Brodie, CEO of Electric Cloud @stbrodie
_____________

.IO! .IO! It’s off to a Service Mesh you should go [Gluecon 2017 notes]
http://bit.ly/2rjw4We

Gluecon turned out to be all about a microservice concept called a “service mesh” which was being promoted by Buoyant with Linkerd and IBM/Google/Lyft with Istio. This class of services is a natural evolution of the rush to microservices and something that I’ve written microservice technical architecture on TheNewStack about in the past. READ MORE
_____________

A few things I’ve learned about Kubernetes
https://jvns.ca/blog/2017/06/04/learning-about-kubernetes/

I’ve been learning about Kubernetes at work recently. I only started seriously thinking about it maybe 6 months ago – my partner Kamal has been excited about Kubernetes for a few years (him: “julia! you can run programs without worrying what computers they run on! it is so cool!“, me: “I don’t get it, how is that even possible”), but I understand it a lot better now.

This isn’t a comprehensive explanation or anything, it’s some things I learned along the way that have helped me understand what’s going on.

Read more from Julia Evans @b0rk
_____________

UPCOMING EVENTS

Rob Hirschfeld and Greg Althaus are preparing for a series of upcoming events where they are speaking or just attending. If you are interested in meeting with them at these events please email info@rackn.com.

2017 New York Venture Summit – LINK

OTHER NEWSLETTERS

SRE Weekly (@SREWeekly) – Issue #76
The DevOps/WebOps Marketing Geek – LINK from @LukasHertig
Julie Evans Blog – LINK

.IO! .IO! It’s off to a Service Mesh you should go [Gluecon 2017 notes]

Posted on June 6, 2017 by Rob H

TL;DR: If you are containerizing your applications, you need to be aware of this “service mesh” architectural pattern to help manage your services.

A service mesh is the result of having a dependency grid of microservices. Since we’ve decoupled the application internally, we’ve created coupling between the services. Hard coding those relationships causes serious failure risks so we need to have a service that intermediates the services. This pattern has been widely socialized with this zipkin graphic (Srdan Srepfler’s microservice anatomy presentation)

IMHO, it’s healthy to find service mesh architecturally scary.

One of the hardest things about scaling software is managing the dependency graph. This challenge is unavoidable from early days of Windows “DLL Hell” to the mixed joy/terror of working with Ruby Gem, Python Pip and Node.js NPM. We get tremendous acceleration from using external modules and services, but we also pay a price to manage those dependencies.

For microservice and Cloud Native designs, the service mesh is that dependency management price tag.

A service mesh is not just a service injected between services. It’s simplest function is to provide a reverse proxy so that multiple services can be consolidated under a single end-point. That quickly leads to needing load balancers, discovery and encrypted back-end communication. From there, we start thinking about circuit breaker patterns, advanced logging and A/B migrations. Another important consideration is that service meshes are for internal services and not end-user facing, that means layers of load balancers.

It’s easy to see how a service mesh becomes a very critical infrastructure component.

If you are working your way through containerization then these may seem like very advanced concepts that you can postpone learning. That blissful state will not last for long and I highly suggest being aware of the pattern before your development teams start writing their own versions of this complex abstraction layer. Don’t assume this is a development concern: the service mesh is deeply tied to infrastructure and operations.

The service mesh is one of those tricky dev/ops intersections and should be discussed jointly.

Has your team been working with a service mesh? We’d love to hear your stories about it!

Bugs Bunny, Prince and Enabling True Hybrid Infrastructure Consumption

Posted on April 23, 2016 by Rob H

OK- Stay with me on this. I’m drawing parallels again. 🙂

Like many from my generation, my initial exposure to classical music and opera was derived from Bugs Bunny on Saturday mornings (culturally deprived, I know). One of the cartoons I remember well was with Bugs trying to get even with the heavy-set opera singer who disrupts Bugs’ banjo playing. In order to exact his revenge, Bugs infiltrates the opera singer’s concert by impersonating the famous long-hared (hared…get it?) conductor, Leopold Stokowski. He proceeds to force the tenor to hit octaves that structurally compromise the amphitheater and as it crumbles leaves him bruised and battered. Bugs is as always, victorious.

bugs

In examining Bugs’ strategy (let’s assume he actually had one), Bugs took over operations of the orchestra’s musical program to achieve his goal of getting the tenor “in-line” so to speak. As I prepare to head down to the OpenStack Conference in Austin, TX next week, I’m seeing similar patterns develop in the cloud and data center infrastructure space which are very “Bugs/Leopold-like”. With organizations deciding on how to consolidate data centers, containerize apps and move to the cloud, vendors and open source technologies offer value, however true operational, infrastructure and platform independence are not what they appear to be. For example, once you move your apps off the data center to AWS or VMware and then later determine you are paying too much or the workload is no longer is appropriate for the infrastructure, good luck replicating the configuration work done on CloudFormation on another cloud or back in the data center. Same rationale is applicable to other technologies such as converged infrastructure and proprietary private cloud platforms. As the customer, to achieve scale and remove operational pain you must fall in line. That in itself is a big commitment to make in a still-evolving and maturing technology industry and a dynamic business climate.

On an unrelated topic, I was saddened to learn of the passing of Prince this past week. While not a die-hard fan, I liked his music. He was a great composer of songs and had a style all to his own. Beyond his music and sheer talent, I admired his business beliefs and deep desire to maintain creative ownership and control of his music and his brand.

prince Despite his fortune and fame, there was a period in the middle of Prince’s career in which he felt creatively and financially locked-in by the big record companies. Once Prince (and the unpronounceable symbol) broke away from Warner Music, he was able to produce music under his own label. This action enabled him to create music without a major record label dictating when he needed to produce a new album and what it needed to sound like. In addition, he was now able to market his new recordings to the distribution platform that supported his artistic and financial goals. While still having ties to Warner Music, he was no longer bound by their business practices. Along with starting his own music subscription service, Prince cut deals with Arista, Columbia, iTunes and Sony. Prince’s music production had operational portability, business agility and choice (seven Grammy awards and 100 million record sales also help create that kind of leverage.).

While open APIs and containers offer some portability, at RackN we believe they do not offer a completely free market experience to the cloud and infrastructure consumer. If the business decides it is paying too much for AWS, it should not allow for the operational underlay and configuration complexity to lock them to the infrastructure provider. They should be able to transfer their business to Google, Azure, Rackspace or Dreamhost with ease. We believe technologies that create portable, composable operational workflows drive true infrastructure and platform independence and as a benefit, reduces business risk. Choosing a platform and being forced to use it are two very different things.

In conclusion, when considering moving workloads to the cloud, converged infrastructure platforms or using DevOps automation tools, consider how you can achieve programmable operational portability and agility. Think about how you can best absorb new technologies without causing operational disruption in your infrastructure. Furthermore, ensure you can accomplish this in a repeatable, automated fashion. Analyze how you can abstract away complex configurations for security, networking and container orchestration technologies and make them adaptable from one infrastructure platform to another. Attempt to eliminate configuration versioning as much as possible and make upgrades simplistic and automated so your DevOps staff does not have to be experts (they are stressed out enough.).

If you are attending the OpenStack Conference this week, look me up. While I am far from a music expert, i’ll be happy to share with you my insights on how to spot a technology vendor that likes to play a purple guitar as opposed to one that eats carrots and plays the banjo.

-Dan Choquette: Co-Founder, RackN

Faster, Simpler AND Smaller – Immutable Provisioning with Docker Compose!

Posted on October 2, 2015 by Rob H

Nearly 10 TIMES faster system resets – that’s the result of fully enabling an multi-container immutable deployment on Digital Rebar.

I’ve been having a “containers all the way down” month since we launched Digital Rebar deployment using Docker Compose. I don’t want to imply that we rubbed Docker on the platform and magic happened. The RackN team spent nearly a year building up the Consul integration and service wrappers for our platform before we were ready to fully migrate.

During the Digital Rebar migration, we took our already service-oriented code base and broke it into microservices. Specifically, the Digital Rebar parts (the API and engine) now run in their own container and each service (DNS, DHCP, Provisioning, Logging, NTP, etc) also has a dedicated container. Likewise, supporting items like Consul and PostgreSQL are, surprise, managed in dedicated containers too. All together, that’s over nine containers and we continue to partition out services.

We use Docker Compose to coordinate the start-up and Consul to wire everything together. Both play a role, but Consul is the critical glue that allows Digital Rebar components to find each other. These were not random choices. We’ve been using a Docker package for over two years and using Consul service registration as an architectural choice for over a year.

Service registration plays a major role in the functional ops design because we’ve been wrapping datacenter services like DNS with APIs. Consul is a separation between providing and consuming the service. Our previous design required us to track the running service. This worked until customers asked for pluggable services (and every customer needs pluggable services as they scale).

Besides being a faster to reset the environment, there are several additional wins:

more transparent in how it operates – it’s obvious which containers provide each service and easy to monitor them as individuals.
easier to distribute services in the environment – we can find where the service runs because of the Consul registration, so we don’t have to manage it.
possible to have redundant services – it’s easy to spin up new services even on the same system
make services pluggable – as long as the service registers and there’s an API, we can replace the implementation.
no concern about which distribution is used – all our containers are Ubuntu user space but the host can be anything.
changes to components are more isolated – changing one service does not require a lot of downloading.

Docker and microservices are not magic but the benefits are real. Be prepared to make architectural investments to realize the gains.

Rob Hirschfeld

On Computing, Containers, Cloud & Tech Culture

Category Archives: microservices