Archive | as a Services RSS feed for this section

Beyond the Network (The Future of the Network, Part 3)

23 May

Beyond the Network

This post the third in a series: To read them in order, start here.

Imagine for a moment that if instead of treating each server (or container, or vm) as if it is one or more network hops away, that the server was directly attached to the services and other servers that it needs to interact with most. This would increase efficiency and would solve quite a few consistency and consensus issues that exist today when dealing with modern infrastructure. If each network switch and router is already a specialized computer, why not further empower these devices to solve many of the problems we struggle with in infrastructure today? We had quite a few specialized network appliances such as load balancers, firewalls, and storage appliances that emerged in the late 90’s and early 00’s. These follow a path of mixing the network with servers providing some specialized function or functions.

The demands for the ever faster evolution of infrastructure capabilities and scale, and the fact that the network is treated as a dumb pipe or simply plumbing between nodes all contribute to the friction of trying to have a dynamic infrastructure. This dumb pipe approach forces all complexity into the software on server nodes, which makes things using distributed systems and solutions vastly more complex than necessary. Trying to create overlays and abstractions just increases complexity and impairs performance as a tradeoff for flexibility.

If you accept that switches and routers are computers that are purpose built for pushing packets, why not consider adding additional capabilities inside these computers? I know there will be naysayers that think this is a bad idea and there will be cases where some of these things may very well be a bad idea. However, there is definitely a class of problems where this would be a far more elegant solution than what we have now.  Simplifying out some complexity and vastly improving performance and scalability seem pretty attractive. A message bus/queue comes to mind as a great example that could start providing incredibly low latencies by being tied into the network device itself.

This approach would also leverage the power of persistent connections, if a server is attached to two other “direct attached switches/network devices” (for redundancy), if either side goes down the other knows. This is an over-simplification that I ask you to overlook for now as I realize there are exceptions/edge cases. Generally when a physical server goes down, the network interface(s) will go down, this would immediately alert any service running on them that this node is down. There could also be a socket or other specialized service running in the switch looking at heartbeat, packet flow, buffers, and communicates with a server side service, maybe via an optimized coordination protocol? This would work well for local clusters, messaging, and similar scenarios. Your cluster needs concensus? No problem if you are only dealing with the concensus service running the switch or router. Even doing cluster concensus across switches and routers would be superior.

Now think about vendors providing prewritten services available to run on switches and routers that can be connected together with serverless functions. This provides a much more flexible and powerful model of “wiring up” infrastructure. Have a function that needs to be more performant and adding additional instances won’t help?  Maybe it should be deployed on an FPGA, or perhaps a special ASIC is added to the switch. I realize that ASICs aren’t as portable/flexible, but perhaps there are common functions where it still makes sense to add ASICs (serialization/deserialization of a protocol for example). Perhaps these FPGAs and ASICs could even be admin insertable via cards or other modular interface wrapped around them? Or perhaps the switch itself is simply more programmable, but adds special function services running on general processors.

There is also an opportunity to enable more sophisticated systems that combine FPGAs, ASICs (TPUs anyone?), GPUs, and CPUs to handle a greater and broader number of problems. These systems would act and be closer to current big iron routers. However, they would be offer a much wider array of capabilities than what is available today. This might be an appropriate place to run a container running a critical piece of OSS infrastructure code for example.

Mock-Switch

[Above is a Mockup of a Switch with FPGAs, Pluggable ASICs, and CPUs]

I have only scratched the surface of this concept in this post, come back tomorrow to read part 4, where we will explore other possibilities.

Advertisements

The Future of the Network, Part 2

22 May

This post is the second in a series: To read them in order, start here.

There are three trends that I have seen happening over the past few years that are indirectly or directly influencing the future of networks; The first is the use of FPGAs and ASICs to solve problems around distributed applications and network loads(specifically I’m thinking of Bing/Azure and several AI projects — including one that chose to go down the ASIC path — Google. The other path that is intriguing is of PISA by Barefoot Networks, which seems on a positive trajectory.

This has been driven by the need for greater performance and better efficiencies in the data center at extreme scale. These efficiencies also translate into very large amounts of capex that ends up being saved. The use of custom hardware in conjunction with software, brings much better returns because of the purpose built nature (which brings increased efficiency and/or performance). This could even be seen as what would be the equivalent of VMware shipping VMware Workstation. This technology provided the foundation for the virtualization transformation of the last decade, all based on making more efficient use of server hardware sitting in datacenter already. Yes, virtualization brought many many other benefits, but the story that initially took hold was better utilization of hardware.

Another trend has been the explosion of infrastructure technologies and projects, of which most are OSS. These projects include a wide array of technological building blocks that have been contributed by many of those same large cloud companies mentioned earlier. However, in addition to these large cloud companies, many other large software companies and some fast growing small companies like Hashicorp, have also developed and released infrastructure technologies (Infrastructure as Code). Technologies such as:

There is a specific category that I would like to directly address:

Network gear has stagnated so much, that pure software infrastructure has taken over a large swath of functionality that should live in software on network equipment. This isn’t a knock against any of the projects above, they are all quite innovative and are answering an obvious unmet need. This is another key indicator that we need to change the nature of the network and how it integrates with what runs on it.

The final trend is that of microservices and serverless aka (lambda/azure functions/cloud functions). This is increasing in popularity very quickly by proponents (and with good reason). What is intriguing about the technology, is that you can write very small amounts of logic/code to interconnect the equivalent of lego blocks of services and infrastructure functionality. This has the same risk as microservices, in that there is also some complexity to be managed (especially if the implementation is not well thought-out upfront). However the benefits in speed of development, scalability and delivery outweigh the costs in most cases from what we have seen so far.

 Venn

So how does all this involve the future of networks? Read Part 3 of this series tomorrow to find out what the future of networks is pointing to.

PaaS Element Types

8 Dec

Please Note : This post builds directly on the previous post “A viable PaaS Model

What are PaaS Element Types?

PaaS Element Types are the constructs required to build a PaaS.  Each PaaS Element Type builds upon the previous, I’m not the first to come up with the overall concept of Types building upon one another, this was inspired by Data Types from Software Development.  It is important to understand that all PaaS Element Types end up being abstractions built upon one another.

Why are they important?

As we move to the new paradigm of application development, architecture, and management, applications will be the comprised of these new element types vs. the traditional patterns and designs we have all become used to.  By fully understanding PaaS Element Types, you will gain not only an understanding of how different PaaS solutions work, but what their capabilities, strengths, and weaknesses are and why they have these characteristics.

Compute, Networking, Storage, what about Memory?

You may have noticed that Memory is not listed as a column, why is that?  Storage is meant to encompass all forms of storage, which includes Memory (Memory is just a very fast form of volatile storage, just as an L1 Cache is even faster than standard memory it is all for storing bits and bytes – albeit briefly).  All of the PaaS Elements have the ability to leverage memory for whatever purpose they may need, but I see no reason to separate memory in the Element Types.

Primitives as defined in the previous blog post

Primitives are the Core Building Blocks of Resources.  What does this mean?  Primitives cannot be reasonably reduced to a more basic/granular bit of functionality.  You may be thinking that an Operating System could most certainly be reduced to a more simplistic bit of functionality and you would be correct if we were talking about us in a traditional Infrastructure, but not PaaS.  Part of the magic of PaaS is the prescriptive nature that PaaS brings, along with the obfuscation in most cases of components such as the Operating System.  In the case of the Operating System, it is also important to recognize that as a Primitive, the OS has not actually been instantiated (it isn’t a running OS).  One final note is that PaaS eliminates nearly all direct ties between code and the OS (There are still limits imposed by the runtimes, etc. which are difficult to avoid – e.g. Mono for .Net support on Linux)

Sophisticates : Composites / Combinations / Extensions of Building Blocks (Primitives)

Sophisticates are built from Primitives, meaning that a Sophisticate cannot exist unless it is backed by a Primitive with some addition, change, or a second PaaS Element Type such as a Primitive or Sophisticate.  A Sophisticate could be built from a combination of another Sophisticate and a Primitive!  Let’s take RDBMS as an example (note that this would just as easily apply to NoSQL solutions, etc).  RDBMS will likely leverage a RuntimeVM, an Operating System, Processes, an Interface, Block Store, Cache, and a File System.  While this may be complex it is hidden by the RDBMS Interfaces, which is part of the beauty of PaaS is exposing this combination as a Service or Extension that can be consumed by an API call or a DB connection.

Definitives : Instantiations (Running) of Primitives and Sophisticates either directly in use or wrapped in Services/APIs creating easily leverage abstractions.

These abstractions allow complex configurations of Primitives and Sophisticates coupled with Application Logic, Dynamic Configuration capabilities, and more.  Definitives are the live and fully implemented abstractions as they consume resources.  This could be a Schema in a RDBMS or a Collection with Documents in it in a Document Store.  Definitives are where all of the specificity occurs in PaaS and ultimately what differentiates applications from each other once they are running.

What can you do with all of this stuff?

If you use the prescriptive side (what a developer writing to a running PaaS offering would do) of PaaS and simply consume it, you can quickly and without a deep understand deploy applications within the limits of the PaaS App Space.  Alternatively you can design your own PaaS with whatever capabilities you require to support the behaviors and design patterns that you need for your App Space.  This is done by using the PaaS Element Types to make choices on the Control Space, which in turn creates the boundaries of the PaaS App Space.

Control Spaces share some characteristics of the App Spaces that they provide, this is because the Control Space operates on the same infrastructure that the App Space operates on.  This is true in the majority of PaaS cases that I have seen to date (it could at least in theory, change).  Control Space components are Definitives built from Primitives and Sophisticates to provide the prescriptive approach to the App Space that makes PaaS an attractive alternative to traditional software builds, configuration, deployments, etc.

The work in mapping Primitives, Sophisticate, and Definitives is not yet finished!

What I have provided is the beginning, not the end.  More work needs to be done in adding additional examples of PaaS Element Types, along with mapping all of the current PaaS offerings to both the PaaS Model and what Element Types are used/comprise each PaaS offering.  In future blog posts with help from different collaborators I hope to accurately map the major PaaSes to the PaaS Model and their PaaS Element Types.

 Comment here on the blog or ping me on Twitter (@mccrory) with your thoughts and ideas.

A viable PaaS Model

7 Dec

What makes a PaaS a PaaS?

I’ve seen many discussions on blogs and twitter around this topic, so much so that many people are tired of talking about it because it always leads to cyclical discussions.  I for one haven’t been satisfied with any of the answers that I have seen.  Some people try to define PaaS with requirements such as it must be on demand, while others say that an API and services need to be exposed.  I disagree with these requirements/constraints on describing PaaS.  I think there is a model should be applied to define what is PaaS, to make this model credible there is a necessity that it can be mapped to most (if not all) current and future offerings defined as PaaS (Which will be a follow-on series to this post).

The PaaS Model

The PaaS Model is made up of two different constructs, which are called Spaces.  These two Spaces serve different purposes, but are composed of the same PaaS Element Types (elements will be explained in detail, in an App Space deep-dive follow-on post).  The Control Space and App Space are show in the diagram below, notice that the App Space is fully wrapped/contained within the Control Space.

Control Space:

The Control Space performs all of the automation, management, provisioning that is required by the PaaS.  Interaction with other lower level components such as an Orchestrator is achieved through API abstractions if/when necessary. The Control Space and its implementation also determine what elements are allowed/exposed to the App Space. Further, the Control Space is responsible for maintaining App Space coherency and dependencies.  While the Control Space is comprised of several separate functions, they may be combined in different manners depending on the specific PaaS implementation.  All of this will also commonly be exposed through one or more API interfaces (this however, isn’t necessarily a requirement in the model presently).

App Space:

The App Space is where end-user/customer applications are deployed, updated, and run.  The App Space is controlled (and commonly coordinated) by the Control Space.  The exposure of PaaS Element types by the Control Space to the App Space is one of the key differentiating factors between different PaaS implementations.  App Space characteristics are controlled by how the Control Space is built/designed along with what PaaS Elements were used to build the Control Space.

  • App Network: The path which applications communicate with app each other and services/resources exposed to apps.  The App Network exposes Network connectivity to the App Space.
  • Executor: The application bootstrapping mechanism for apps being or currently deployed.  The executor provides compute/memory resources to the App Space.
  • Code Processor: Examines code, libraries, and dependencies before sending to the Engine and/or Executor.  This can also be thought of as a code inspector or post/pre-processor.
  • Coordination Network: Where the Control Space components communicate/coordinate with each other.  Think of this as a management network that is in most cases out-of-band from the App Network.  The Coordination and App Networks could be combined, however in a production system this would introduce too large of a security risk.
  • Engine: Coordinates the distribution and provisioning of code, services, and their dependencies (most frequently in the Control Space).  The Engine decides the where and how of what happens in the App Space.  Also, the Engine may be capable of coordinating with an Orchestration Layer or other automation tools outside of the Control Space to provide new/additional resources to either/both the Control Space and the App Space.
  • Monitor: Looks at the state of the App Space and the Control Space, signaling other Control Space components to resolve conflicts.  The component most likely to resolve conflicts would be the Engine or a specialized component designed purely for conflict resolution.
  •  Notes: These components/functions may be grouped differently based on the specific PaaS implementation.  Also, some of the functionality or components could be put into an API, split into sub-components, or even externalized through/in a Client or Client side API.

PaaS Elements:

PaaS Elements are abstractions on top of different layers of resources.  Most PaaS Element abstractions are done through Service based or Service centric abstractions.  This is not the only way of creating/doing an abstraction, but it is one of the most flexible ways.  PaaS Elements are broken up into three primary types which are defined below:

Please note there will be an in-depth post on PaaS Elements following this blog post.

  • Primitives : The Core Building Blocks of Resources
  • Sophisticates : Composites / Combinations / Extensions of Building Blocks (Primitives)
  • Definitives : Instantiations of Primitives and Sophisticates either directly in use or wrapped in Services/APIs

All PaaS Elements have the ability to provide or interact through a pass-through interface or abstraction to any other PaaS Element type all provided by the Control Space.  Elements are combined to create an Application (App) in the App Space.  The most interesting twist to the model is that the Control Space is made up entirely of PaaS Elements as well.  There is a great deal more to be covered on this topic both here on this blog and out in the community.  Please provide feedback and questions in the comments section of this post or live on Twitter (@mccrory)

I would like to give a special thanks to Shlomo Swidler (@shlomoswidler) and Derek Collison (@derekcollison) for providing valuable feedback in several draft iterations of this post.

Defying Data Gravity

2 Apr

How to Defy Data Gravity

Since I have changed companies, I have been incredibly busy as of late and my blog has had the appearance of neglect.  At a minimum I was trying to do a post or two per week.  The tempo will be changing soon to move closer to this….

As a first taste of what will be coming in a couple of weeks I thought I would talk a bit about something I have been thinking a great deal about.

Is it possible to defy Data Gravity?

First a quick review of Data Gravity:

Data Gravity is a theory around which data has mass.  As data (mass) accumulates, it begins to have gravity.  This Data Gravity pulls services and applications closer to the data.  This attraction (gravitational force) is caused by the need for services and applications to have higher bandwidth and/or lower latency access to the data.

Defying Data Gravity, how?

After considering how this might be possible, I believe that the following strategies/approaches could make it feasible to come close to Defying Data Gravity.

All of the bullets below could be leveraged to assist in defying Data Gravity, however they all have both pros and cons.  The strengths of some of the patterns and technologies can be weaknesses of others, which is why they are often combined in highly available and scalable solutions.

All of the patterns below provide an abstraction or transformation of some type to either the data or the network:

  • Load Balancing : Abstracts Clients from Services, Systems, and Networks from each other
  • CDNs : Abstract Data from it’s root source to Network Edges
  • Queueing (Messaging or otherwise) : Abstracts System and Network Latency
  • Proxying : Abstracts Systems from Services (and vice versa)
  • Caching : Abstracts Data Latency
  • Replication : Abstracts Single Source of Data (Multiplies the  Data i.e. Geo-Rep or Clustering)
  • Statelessness : Abstracts Logic from Data Dependencies
  • Sessionless : Abstracts the Client
  • Compression (Data/Indexing/MapReduce) : Abstracts (Reduces) the Data Size
  • Eventual Consistency : Abstracts Transactional Consistency (Reduces chances of running into Speed of Light problems i.e. Locking)

So to make this work, we have to fake the location and presence of the data to make our services and applications appear to have all of the data beneath them locally.  While this isn’t a perfect answer, it does give the ability to move less of the data around and still give reasonable performance.  Using the above patterns allows for the movement of an Application and potentially the services and data it relies on from one place to another – potentially having the effect of Defying Data Gravity.  It is important to realize that the stronger the gravitational pull and the Service Energy around the data, the less effective any of these methods will be.

Why is Defying Data Gravity so hard?

The speed of light is the answer.  You can only shuffle data around so quickly, even using the fastest networks, you are still bound by distance, bandwidth, and latency.  All of these are bound by time, which brings us back to the speed of light.  You can only transfer so much data across the distance of your network, so quickly (in a perfect world, the speed of light becomes the limitation).

The many methods explained here are simply a pathway to portability, but without standard services, platforms, and the like even with the patterns etc. it becomes impossible to move an Application, Service, or Workload outside of the boundaries of its present location.

A Final Note…

There are two ways to truly Defy Data Gravity (neither of which is very practical):

Store all of your Data Locally with each user and make them responsible for their Data

If you want to move, be willing to accept downtime (this could be minutes to months) and simply store off all of your data and ship it somewhere else.  This method would work now matter how large the data set as long as you don’t care about being down.

IaaS and SaaS lead to PaaS

13 Feb

Most people currently portray the Public Clouds as a stack consisting of IaaS, PaaS, and SaaS.  Worse still, they try to define Private Clouds in the same way. In a discussion I had with Christofer Hoff@Beaker he accurately pointed out that this isn’t entirely the case, that they are all really Integrations.  This blog post was about three sentences in when a discussion broke out on Twitter regarding IaaS and ultimately where IaaS and SaaS converge – hint: PaaS.

IaaS and SaaS lead to PaaS

IaaS is becoming established by many Public Cloud providers by providing Virtual Machines, Block Based and File Based Storage, Databases and Key Value Stores, and several other core capabilities. As these capabilities become more sophisticated and their complexity increases, the drive to abstract and re-simplify pushes IaaS toward PaaS. IaaS is beginning to also take root in Private Clouds (Enterprises) where there is a motivation for more automation and self-service in an attempt to drive more efficiency. What Private Cloud providers (I’m thinking of IT) will find is that they are unable to achieve the same levels of efficiency that Public Clouds can. The difference between Public Cloud IaaS and Private Cloud IaaS efficiency isn’t entirely based on scale as you might initially think. The disparity is also driven by the storage philosophies that they follow or rather the difference.

Public Cloud IaaS is driven by very cheap and very scalable storage using software based redundancy with many replicas of data (think multiple copies on JBOD). Private Cloud IaaS in contrast is driven by highly available, fault tolerant, hardware redundant disk arrays (think SANs). This difference in storage methodology translates into a difference in Platform Methodology, Applications Methodology, and Operations Methodologies. Data is king and the assumptions that are made around how data is persisted and retrieved drives decisions about platforms, applications, and operations.

When Private Clouds embrace some of the newer approaches in storage, they will also embrace change in their Platform, this is where PaaS enters the picture in a big way. PaaS will also be pushed by applications developers because of the increases in productivity and efficiency that it brings to Enterprise Development Organizations. The changes to the Enterprise Development Orgs mean changes to Application Design Methodologies. These changes will drive IT to make changes as well because previous Operations Methodologies will no longer work (I’m looking at you traditional ITILv3). There will also be deep security implications to all of these changes, however this will neither make security better or worse, just applied differently than it is presently.

We’ve covered the IaaS angle and how it pushes toward a PaaS centric world, but what about SaaS? I find it interesting that SaaS has been with us for 10 years now, yet many people are just realizing its value. The defacto example of SaaS is Salesforce.com. Virtually every article that talks broadly about SaaS mentions them, mainly because almost everyone has heard of Salesforce and has probably interacted with it at some point in their career. Public Cloud SaaS has several issues that it struggles with, two of which are the need to maintain a shared infrastructure in order to keep costs low but still keep customer data separate. The second issue being the need allow customers to customize the solution to meet their needs (this could be through integrations, add-ons, or other applications). Making this work if you are simply delivering pure software as a service is difficult if not impossible. This has led Salesforce and other providers to slowly transform into more of a Platform that offers Software and less of a traditional or pure Software as a Service solution.

Public SaaS Cloud moves toward PaaS because of customer demands for isolation and customization, but what about Private SaaS Clouds? Private SaaS Clouds are more about the delivery and management of the software by IT. This pattern of an Enterprise being its own provider or contracting to a Hosting Provider for these services will still drive them to want capabilities that are not out of the box. This drive will lead them down the PaaS path as well.

PaaS no matter what it ends up looking like is much closer to what the end state looks like than IaaS or SaaS.

The Future of PaaS in the Enterprise – The Service Oriented Platform

26 Jan

Anyone who followed Cloud Computing last year watched several changes occur throughout the space.  These changes were happening in the view of what Public, Private, and Hybrid Clouds were defined as, the interest in IaaS solutions in the Enterprise and within Service Providers, and finally a renewed interest in the potential of PaaS.

Currently Public PaaS solutions are focused on core compute functionality and persistent services all of which are being backed by some mix of IaaS (with or without Virtualization, more with than without though).  Why are so many Public PaaS focused on their IaaS underpinnings?  Two reasons come to mind, IaaS is easier for customers and IT to understand and yet generic enough to have the broadest appeal.  This is important in the continuing evolution of the Cloud market as a whole, we need the widest adoption possible early on for any Cloud Platforms to take off.

Now, focusing in on the set of events around PaaS in the past year brings us to the rumors that surrounded EngineYard’s acquisition by VMware (which never happened and now we see that Amazon is working with them on a Ruby on Rails Elastic Beanstalk), Heroku was acquired by Salesforce.com, VMware announced the Open PaaS solution, and Microsoft will fight with anyone who calls Azure anything but a PaaS.  All of this Public facing PaaS news sounds great, but I’m sure you are thinking how does this translate to Enterprise?

I wondered this same thing and began to try to figure out just where it all leads.

What is the Future of Enterprise PaaS?

Public Cloud Services are always different from Private Cloud Services, many people think that Hybrid is something easy but miss the nuances involved with implementing Hybrid Clouds.  I’m not saying that achieving a Hybrid model is impossible, just that there are many hurdles and few have working solutions that seem to address most or all of them.

PaaS in an Enterprise will operate as a Service Oriented Platform.  That sounds like a silky smooth sentence doesn’t it?  But there is substance behind the statement.  Today the most advanced Public PaaS platforms are focusing on generic, on-demand, multi-tenant, infrastructure components, and other core capabilities.  What Enterprises will need for PaaS will be this plus many other services including specialized components such as vertical specific ERP and CRM solutions exposed as services, legacy solutions with service bridges, Big Data service connectors, and many more.  As these capabilities get built and each former “Silo” gets exposed as a service a Platform will emerge.

About the Service Oriented Platform:

Something to understand is that each business is different, it was formed differently and while it operates most likely in a similar fashion to other businesses in that market, it is still different.  This difference becomes even more pronounced when the needs are pushed to IT (Operations and Development).  This would be the equivalent to the Butterfly Effect in IT.

Why does the Butterfly Effect matter for an Enterprise Service Oriented Platform?

Because it means that each Enterprise Service Oriented Platform will be DIFFERENT than all others (maybe only marginally, but still different).  Each service exposed to the ESOP will be a new capability that Devs can leverage as they put together Apps on top of the Enterprise PaaS.

Something that may be important to realize is that IT Operations may view the solution as an ESOP while Devs may view it as an Enterprise PaaS.  I think both of these are actually correct and will talk about the same thing, it is just how it is being viewed and by who, but it is still the same thing.

Hybrid Clouds will be exposed as another service capability:

Hybrid Clouds will be Public Cloud services that are exposed either directly or indirectly to the ESOP.  The ESOP will have the control, authentication, metering, and likely the QoS.  The EPaaS will have the allowed/exposed services and resources from the Public Cloud.  This will be at a different level than simply pushing and pulling VMs, Virtual Hardisks, or Creating VPNs.

I’m interested in people’s thoughts and comments:

Comment on this Post or Follow Me on Twitter – @mccrory