Tag Archives: TECH

Roster cuts

It’s football season (Hallelujah! Go Pats!) and going into the season, every team just finished making the roster cuts necessary to get down to 53 men.

Hmmm…something about that sounds familiar…OH, right!

It’s VMworld and going into Tech Field Day, we just finished making the slide deck cuts necessary to get our presentation down to 53 minutes.

The morning before TFD, we killed a slide. It wasn’t a bad slide, but there was discussion of how the deck was already long, the speaking slot short, and the slide perhaps a bit redundant. All told, the deck was 24 slides, and I think we created and didn’t use another 24 slides as we crafted and refined our story.

The presentation went great – Peter and Scott did an amazing job talking about our architecture and demonstrating the new features of version 2.0 of our product. Check it out here.

But the last slide we killed stayed with me. Not because it was the greatest slide, or the worst slide, but because I think it says something interesting that as the product marketer I didn’t capture compellingly enough to justify its remaining in the deck.

Here’s the original slide:

See? It’s pretty interesting – it takes six important pieces of the datacenter and provides a factoid about each one. After that, we focused in on why there is so much pressure on storage, since that is the problem our software solves.

After that, the story continues with a discussion how different vendors are solving the problem of pressure in storage, and how our solution is differentiated from them. We ended up removing the first slide above and just starting the story with the second slide.

What I didn’t capture right in the deck is the interconnected-ness of these components. I’m going to take storage out of it for a moment, because that’s the component whose change we want to analyze. So, if you look at what is enabling Applications and Virtualization to change in these ways, it’s the changes in CPU, Memory, and Networking. Conversely, the innovation in those areas is being driven by the Application and Virtualization growth.

Kind of like this. (And to get really technical about it, I’d say that 10GbE networking is even more impactful for cloud-based apps than it is for virtualization, we can keep the image simpler.)

Now we can look at what is driving all the pressure on storage. CPU, Memory, and 10GbE are enabling applications to get faster (and scale out) and virtualization to consolidate more densely. But the 10GbE network isn’t just enabling applications and virtualization, it’s also the pipe directly to the storage – so it’s a direct factor as well:

And one final touch on that slide – the major disruption in storage itself – flash technologies dropping in price – are causing pressure on storage. Flash means more I/O able to be processed on the storage, IF the storage processor can handle the uptick in IOPS. And flash needs special handling for things like garbage collection and wear leveling. So that’s more pressure storage is putting “on itself.”

Blog_post_slides_pptx_3

So that itself would have been a better first slide – and in fact may have negated the need for the second slide.

Stay tuned for another post early next week on what else is interesting about this slide that didn’t quite make the roster…err…deck.

Heading right out of my comfort zone

IT and the cosmos

Life moves pretty fast…

2 Replies

When I started in the industry, it was in data protection. Except back then, we called it “backup.” I quickly learned that my ability to hold a conversation in the domain was predicated on my understanding some fundamental technological concepts.

For example, I had to understand multiplexing, shoe-shining, grandfather/father/son tape rotation, what it mean that Exchange didn’t really quiesce, and what a backup window was.

Over time, being able to talk about backup meant knowing a different core set of concepts. Today, the category would be called “data protection,” and you’d have to know about snapshots, backup-to-disk, deduplication, and offsite replication, for starters.

When I was at Dell, I transitioned from being a sales engineer to being a storage specialist. Suddenly, I had to learn the fundamental storage concepts – and quickly. At the time, they were (roughly): RAID, more disks means more IOPS, disk contention, storage virtualization, usable space, and automated tiering.

This stuff is barely relevant in storage anymore. Or, maybe it’s more like the information has commoditized. It’s taken for granted now that we know which RAID types are appropriate for what workloads; that’s no longer a consultative value-add that a vendor can provide. You get into a discussion with someone and mention some of this, and it’s so basic it destroys credibility.

And that happens incredibly quickly. Less than a year ago, it was still interesting to talk about storage performance and storage capacity being resources that should be managed separately, now that is not considered “thought leadership,” it’s internalized into the collective consciousness of the industry.

So what are the fundamental concepts now?

Content-based storage, I think. Server-side cache and all-flash arrays. Distributed scale-out systems, object storage, variable-block deduplication. Software-defined anything. Converged systems. I bumped into two other products this week (in addition to my own) that use are content-addressable with a consistent hash.

As a childhood hero of mine said, “Life moves pretty fast….”

3 dumb questions I asked last week

2 Replies

Every day for the first 12 years of my education, my father sent me off to school with a single piece of advice: “Ask good questions.” Question by Tim O'Brien

He has a few other standards (doesn’t everyone’s dad?), but this one has always stuck with me. I think it’s a major contributing reason as to how I ended up in technology.

Right now I’m in the phase of learning where the good questions are dumb questions. Because when we say, “I have a dumb question” what are we really saying?:

“I want to ask about something that I think that you think that I should already know”
or
“I want to ask about something that seems really basic but I don’t understand”
or
“I want to ask about something that I think everyone else in the room already knows”
or
“I want to ask about something that seems to be accepted but I don’t believe.”
or
“I want to ask about something that you didn’t explain very well.”

I love asking dumb questions. Because they usually aren’t that dumb. And right now they are the key to my building a strong foundation of knowledge and capability.

So I think they are good questions. Here are some of the ones I’ve asked recently:

1. Why is our product called a “content-based cache?” Aren’t all caches caching content?

Well, yeah. Usually. But when we say ”content-based cache,” it is in contrast to “location-based cache.”

Location-based cache says “oh, you asked for the data in slot 7 already. I have that slot 7 data, here it is.”

Content-based cache says “oh, you asked for the data whose hash is xyzabc. I have the data whose hash is xyzabc, here it is.”

The benefit of using a content-based caching scheme is that if the same data is in two places, it only has to be stored in the cache once. That makes the cache’s logical size larger.

2. So is write-through cache write cache or not?

Write caching comes in a few flavors. Write-back cache might be what you think of when you think of write caching. When writes come in, they are written to cache immediately. At some point, they get moved to more permanent storage (or not.)

Write-through cache is what Infinio does. It doesn’t mean that we aren’t caching writes – in fact, every write that comes in is added to the cache. However, the original write is also committed to the storage system immediately. This “warms” the cache by putting the most recently written data into it. However, unlike write-back cache, there’s no point in time in which the data is only in cache and not also on disk.

Write-through cache is not as fast as write-back cache, because the data is being written all the way to disk, not just to local (faster) cache. But it is less risky because all writes are going through to disk. For our solution, it also means you don’t have to make any changes to your storage system because snapshots, replication, etc., all work exactly the same way as before Infinio.

3. What’s all this discussion about Offload vs. Acceleration?

My first day, I sat in on a meeting where for 30 minutes we discussed whether we do offload or acceleration. I say “we” but I had no idea what was going on. There were metaphors involving cars and engines that were not helping me understand anything any better. I asked someone to explain it but it felt like all they were doing was describing the product again.

As it turns out, here’s what they were talking about:

The core function of our product is to offload read requests from the storage system by serving them from our cache. There are a lot of benefits that come out of this offload:

Some reads are much, much faster if you are requesting data that is in your local piece of the distributed cache.
Some reads are much faster if you are requesting data that is anywhere in the distributed cache.
Because fewer requests are going to the storage system, the requests that are can be served more quickly because the storage system is less busy.

Technically, the first two are acceleration and the #3 is offload. You’re welcome – now you don’t have to go to a meeting about this.

I feel pretty confident that this “dumb question” phase is far from over. I’ll share my next few shortly.

Three meetings that didn’t suck

2 Replies

“If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be ‘meetings.’ (Dave Barry)”

One of the things I’ve noticed as I’ve adjusted to life here at Infinio is that we have different types of meetings than I am used to from being at a big company.

First off, we have a lot more ad-hoc meetings. Perhaps due to the open floor plan, it’s far more common to mosey over to someone’s desk and start chatting rather than to schedule time with someone. “Can I grab you for a sec?” “Are you interruptible?” are very common here.

Twice a week I participate in a marketing “stand up” meeting. I remember reading about these in grad school as part of Agile/Scrum methodology, although not really related to marketing. In ours, we go “around the horn” and everyone does a quick update of their major goals for the day. Sometimes we have a short conversation about something or show a piece of work off, but usually it’s just to set up for the day. Oh, and it’s called a “stand up” meeting because we literally “stand up.” That keeps it nice and short.

Last Friday I went to my first engineering iteration meeting. I am such a dork – I was really (*really*) excited to attend. Engineering at my last job was not a resource directly accessible to me so it was exciting to see what happens in one of their meetings. Basically, the engineers took turns talking about their work on particular features or problems, with at least 6-8 of them talking in a 2 hour meeting. People asked questions and expressed worries, and there was a lot of sharing of images and screen shots. We used Google Hangouts to connect to remote engineers so the graphics were definitely important.

I learned a few specific things at the meeting.

1. Despite being warned that I might be bored I was pretty well-equipped to follow most of what was going on in the meeting. With the exception of some coding buzzwords, the bulk of the things I didn’t understand had more to do with my gaps in knowledge around VMware than anything else.

2. The relationship between engineering and QA is fascinating – like siblings maybe? Everyone wants to release a great working product but it’s QA’s job to poke holes in the code before it ships. (Nudge, nudge, poke, poke, I’m not touching you….) The groups were friendly and respectful towards each other.

3. Regarding language – I was impressed by how many times “the customer” was referenced (17) and how actively they seemed to be a silent participant in the meeting. Specific customers were also mentioned and resolving their issues was clearly top priority. There was also some reference to “technical risk” and “technical debt” which were new concepts to me.

4. Finally, I understood – immediately, in a flash – what automation testing is and why it’s so important. Suddenly, too, I understood what “DevOps” meant. And I’m not sure either of those things would have made any sense if I hadn’t attended that meeting.

The other new kind of meeting I have begun attending since joining Infinio is the weekly all-company meeting. After our company lunch on Wednesdays, our execs all get up and talk about what’s going on in their domains – Engineering, Sales, Marketing, and our CEO. They share good news and bad news and major strategic decision-making.

It was really fascinating to see the engineerings ask about marketing programs and plans – it reminded me that you can’t just wake up one morning and decide to do marketing well any more than you can wake up and decide to do engineering well. I forget that sometimes – even my own biases work against the field I’ve chosen to work in. The other cool thing about the all-company meeting is what happens afterwards – people walk over to each other and follow up on things they heard. It’s another good way to get engineering, sales, and marketing talking. A test engineer came over to me to comment on some market research I was doing because he had worked at one of the companies whose technology I was researching. Score!

I like meetings that don’t suck. I hope to attend more of them.

CREATE TABLESPACE Blog

4 Replies

I’m glad you found yourself here.

You may know me (and some of this) from Twitter, but to level-set: At the end of January, I left my job in solutions marketing at Dell after 7 years.

kendall After a short hiatus, I joined Infinio Systems – a software startup in Kendall Square – as Director of Product Marketing. There is so much to digest and learn, and there’s no way to share the experience in 140 character chunks. So here I am in the blogosphere.

So why name my blog “storageDiva’s Tablespace”? Two reasons:

A tablespace is the abstraction layer in a database that sits between the logic of the database and the physical datafiles it contains. Basically, you group several tables and indices together and while they are physically stored in datafiles, the collection of them (regardless of physical location) is a tablespace.

I like the metaphor of this blog being a tablespace of interrelated tables, because I plan to share all sorts of interrelated ideas about my experiences in technology, marketing, and life at a startup. Here’s a swag at what I think the “tables” would be called:

LEARNING: My education around caching, performance, and all things Infinio
CUSTOMERS: What I learn from our customers and our not-customers
TECH: Thoughts and ideas about our product and the industry at large
MARKETING: How product marketing is changing in the Internet/Social Era
STARTUP: Life at a startup, especially after coming from a big company
XX: What it’s like to be a woman working in technology
HOME: Balancing my work life with my daughter(“babyDiva”) and spouse (“mrDiva”, also at a startup)

I said there were two reasons for the blog being called “storageDiva’s Tablespace.” The second reason comes from Sheryl Sandberg. In her book and TED talk she relates a story of being at a meeting and notices that the young women are sitting on the periphery of the room while the men all sit at the table. She urges the women (and the reader/watcher) to claim a seat at the table (not behind it) to ensure their voice is heard.

The phrase “table space” is a reminder to myself that I have gotten where I am by always claiming my space at the table, long before the other Sheryl made it trendy.

I hope you’ll stick around.