When we think about networking, we think about things that go bump in the wire—things that place bumps in the wire. Such things could be switches, load balancers, firewalls, routers, gateways, etc. The list is not all that long, thankfully. Things that put bumps in the wire are at odds with software-defined networking (SDN). SDN relies upon key services to exist. These services are DNS, identity management, and key management. Without these, many systems would fail outright. However, they are not considered network functions. Network functions are considered to be the bumps in the wire we need to make applications work. The goal of network functions virtualization (NFV) is to streamline this process, to reduce complexity while maintaining compatibility. NFV and SDN together lead to an interesting mix of hardware and software, and some of these just do not interoperate well. Is there a better solution?
Articles Tagged with API
Someone suggested “the next-generation data center” to me as a topic for an upcoming panel discussion. Here are my thoughts on the subject.
In a recent Twitter conversation, I asked if serverless is anything new, and if so, where are the documents expressing what is new about it. I was asked in reply if I needed a document to understand the difference between Uber and taxicabs. That got me wondering: is the serverless movement a business plan, or is it an approach to technology? If it is a business plan, then it is about how to make money; if it is an approach to technology, it is about architecture. It could also be a combination of the two. Serverless is also known as servicefull. But before we delve further, let us consider the difference between Uber and taxis.
I have spoken and written quite a bit on the delegate user problem facing cloud and virtual environments. It is a growing problem, as we delegate actions from logged-in users to service accounts to implement changes on our systems. Any system, for example, that proxies administrative requests suffers from the delegate user problem. In essence, when we go to determine who did what, when, where, and how, forensics leads us to a delegate user or service account. We do not know beyond a shadow of a doubt who the user really was. We can correlate multiple log files, and based on time we may be able to come up with a set of users who could have done the deed. However, unless only one user was involved, we just end up with a set of users. Those sets of users, themselves, can be other service accounts—other delegate users, abstracting the real user.
On the 9th of May, 2014, something happened in the US Court of Appeals for the Federal Circuit that could have massive ramifications for our fledgling cloud orchestration industry. Circuit judges with no knowledge about the software industry and how that industry works made a judgement that could pull the rug out from under the whole integration and orchestration industry. “What!” you say?