[irq]: serially techie

network pieces

Incomplete thought [props to Hoff]…

I think that control plane and data/forwarding plane separation will end up a common feature of data center networks at scale, for cloud, etc. It’s a lesson from telcos.

The work of control plane software optimization is really a set of algorithmic route calculation (etc.) and distributed database problems that are better attacked outside the confines of network hardware, with general purpose machines.

The work of the data plane is more about capability optimization in asics, fpgas, etc. for latency, latency jitter, scaling, subscription rates, etc.

These two things have very different cycles and [I think] are better off not tied to one another.

analytics at network edges

Incomplete thought…

Much churn and anguish to remove the network limits to scaling virtualized environments has driven people to make the network “aware”, “intelligent”, and “smart” with a focus on virtualization, orchestration, etc.

In this, I think a useful idea has been lost—

The network should provide more intelligence. How about we embed serious awareness in the form of analytics capabilities into the network? Instead of discovering distributed/networked/cloud application hiccups, failures, overloads, etc., at the core and after the fact—I want to intercept and predict them at the edges where they start. There must be markers and patterns to requests, responses, session states, etc., that can be teased out and understood by the edge.. and once observed, passed on to correlators, orchestrators, management systems, etc.

Ultimately, I think there are decisions and actions that should be made/taken at the edge to head off certain kinds of problems before they manifest application-infrastructure-wide.

.

representing non-linearity in project execution

Typically, projects are broken down into constituent activities and tasks and then presented as a two-dimensional process proceeding linearly through time. The overlapping, looping, and conditional flows of activities in an actual project tend to get lost. Critical go/no-go decision [i.e. inflection] points, if identified, are not accurately placed in time or process.

Project management software sucks and is workflow ignorant.

From both the execution side and the client side, misunderstandings (and associated risks) pile up—caused by trying to cram complicated workflows into oversimplified procedural representations. This old hat to most people who run projects or work in the services business. But, there are few approaches to resolve this issue that aren’t mostly manual.

Why don’t people who run projects just use flowcharts? Flowcharts don’t map well to time.

Instead of presenting activities in a “1 then 2 then 3…” fashion, they could be presented as dependency clusters separated by critical milestones-in process and time-that are go/no-go decision points. Each go/no-go decision could then have an associated set of actions undertaken depending on the decision: continue, return to activity x, etc.

portfolio vs go-to-market

[Context: technology services business.]

The portfolio is composed of service offerings. Who delivers the services and how is highly variable, but it only matters that they can be delivered. In general, there’s a 1-to-1 between the services in the portfolio and those sold in the marketplace. That which is marketed is a discrete element in the portfolio.

Marketing messages come and go. Things that clients need (and think they need) come and go. “Solutions” come and go. But skills and delivery capabilities are much less volatile over time. The portfolio represents both an internal capability (to deliver a particular service) and an external presentation of that capability to the marketplace. When there’s a 1-to-1 between the two— 1) the go-to-market becomes brittle because these things change at differing rates or 2) the portfolio becomes littered with things that don’t make sense, overlap one-another, etc., in order to match the moment’s marketing vogue.

If you break the 1-to-1, then the portfolio can represent an internal capability while the go-to-market represents the set of solutions that are selling, that will sell, and that you want to sell in the marketplace. What parts of the portfolio make up any given solution become variable and go-to-market solution development becomes a composition task. If and only if a legitimately new service capability is needed to deliver a solution, such capability is developed and added to the portfolio.

These tools should not be sources of brittleness and inertia, but instead of flexibility and competitive advantage. Make’em so.

The portfolio != the go-to-market.

virtualization networking knowhow

A working list of what matter when designing and implementing data center networks for virtualized environments..

• basics of how the virtualization platform (hardware + hypervisor) does networking
• network demands of the apps being virtualized so you can handle new traffic patterns and capacity demands
• deciding when it’s easier/cheaper to just over-engineer network capacity vs designing to application specific requirements
• traffic between application tiers
• traffic to and from the front-end of the application stack out towards the end user
• how app tiers are virtualized and where the virtual servers are placed relative to each other and the rest of the infrastructure
• how each app tier scales [it might not be the same for each tier]
• virtual switching within the virtualization platform
• virtual switching across multiple instances of the virtualization platform / across multiple machines
• how virtual switching interacts with physical switches
• how the virtualization platform executes VM movement, how much network capacity it eats up, etc.
• how the external network switches deal with these motion events, special features, etc.
• vendor approaches for maintaining network characteristics and state during motion events
• cross L2-boundary or x-DC motion specific
  • WAN capacity needed
  • L4-7 acceleration application
  • whether L2 extension or continuity is required
    • WAN requirements
    • are you going to use MPLS, VPLS, EoMPLS, L2VPNs, Pseudowires,etc.?
    • is it going to be a managed service from a carrier? how do you interact with that? what features do they provide?
    • if it’s WDM over dark fiber, how many lambdas are you going to use for what? do you dedicate one for VM mobility?
    • how do you control broadcast traffic?
  • if no L2 continuity is required, how do you get requests to the new location / IP address? GSLB?
  • must understand architectural basics of the storage involved
    • location
    • latency tolerence for storage access
    • does the storage move when the VM moves? is it pre-positioned?
    • storage replication and latency issues with that and bi-directional primary/secondary volume requirements, etc
• network provisioning and automation tools, how they work, etc.
• if the infrastructure will be treated as multi-tenant, what kind of implications that has on network segmentation and isolation and placement of network services (including security)

enterprise skeleton

[Originally posted august 2008 to my old blog.  ”Very Smart People” are just folks who can get things done, cut through the morass of bureaucracy, don’t work with blinders on, etc.]

People vary.

The bigger the organization, the greater the variance. You can try to build a company of only Very Smart People. But beyond some size, there’s no way. People vary.

In every part of the enterprise, some number of people will do things that are in some way in variance with the [stated] goals of the business. Depending on who these people are and what their influence, their decisions ripple out—having unpredictable impacts on the business.

These things happen. Adapt.

For every X people, there’s a Very Smart Person (VSP) who others turn to when things break down, when problems aren’t being solved, when there are hard questions. VSPs short-circuit complex processes, organizational boundaries, and chains of command.  They exist in every part of the enterprise, every kind of job, every rank, etc.

They form the skeleton of the enterprise. They can move everyone in a generally desired direction and correct/compensate for any number of deviations. But as far as I’ve seen, they’re not necessarily (and perhaps rarely) executives. And they may not ever want to be.

The org chart != the operational structure of the enterprise.

cloud + soa = service oriented infrastructure

Boiling service oriented infrastructure down to three points..

• Self-service to an application (instead of to the user)
• Programmable API interface to a set of infrastructure or platform services
• Resource access, provisioning, scaling, etc., is done/initiated/requested  directly by the app that needs the resources within the bounds of some policy

[Background: application driven hardware, service oriented infrastructure]

brooklyner curatorial

fyi— I’ve got another tumblog going called brooklyner curatorial. It’s lo-tech: music, videos, and varied web stumblings.

tools that move

Tools need to move when we do. They must be made to be moved by us.

The idea of user-driven innovation should be built into tools and applications. When something is modified by a user, that should make everyone involved in the development, sales, marketing, etc., of that thing to pay attention.