Wednesday, May 07, 2008
In my second video of a planned series of videos (number yet to be determined), I interviewed Tudor Toma, Group Program Manager and Soumitra Sengupta, SSDS Architect about the business value of SSDS.
Watch the Video
One point that I want to emphasize is that from a business perspective, SSDS tackles two of the biggest pain points that companies have to deal with today when creating new IT systems: capital expenditures (CapEx) and operational expenditures (OpEx). Beyond just the dollar cost of how much software costs to create, you need to think about how much hardware or hosting will cost. You have to plan capacity and guess the load the system will generate. Next, you have to figure out how many support personnel will be required to maintain the system. Someone has to maintain the software, repair machines when they go down, defrag, patch, update, etc.
One of the greatest business values (as opposed to technical values) you get from SSDS (and cloud services in general) is the ability to redeploy the capital to other resources. In the case of CapEx, you can deploy this perhaps to marketing or content creation. In the case of OpEx, those expenses can be redeployed to more useful tasks in the enterprise (creating new systems, upgrading, and expanding operations perhaps?). While there are opportunities to just save this money, I think more realistically the money is going to get spent on the other things that you wished you had time and resources for.
I think the value is easy to understand from a startup's perspective. But even enterprise users should be thinking about this. Big budget IT programs could easily be switched out to cloud services at a fraction of the cost to build out the support and infrastructure needs. Money that would otherwise be spent for disaster recovery (you do DR planning, right?) can be re-purposed or saved. The days of multi-million dollar new IT investments are numbered in a lot of cases in my opinion. I can still see a few cases where it would be necessary depending on a companies core value proposition, but for a majority, it just doesn't make sense.
Sunday, April 27, 2008
I just tried out the new Amazon MP3 store and the accompanying MP3 downloader. So far, it seems like a nice piece of unobtrusive software (unlike that evil, evil iTunes POS). Although I was not a fan of the Unbox service, I think I have found where I will be downloading music from now on...
Saturday, April 12, 2008
I recently moved and had to get Comcast. Is there any other business entity in the world that is so despised as cable companies? The RIAA is close, but you are much more likely to deal with cable companies than the prior. Warning: ranting to follow...
Part I: Ordering
Calling Comcast to order packages found on comcast.com is an exercise in futility. First, the rep will spend 20 minutes trying to upsell you to their damn $99 triple play bundle. My favorite part of that experience: If you tell them you are not interested in the phone service (I am not) and you use the word VOIP, they will correct you: "no, no... it is not *VOIP* sir, it is *secure* voice communication over your cable line". Ahh... I forgot that Comcast sells magic flippin' fairy dust that makes the IP packets carrying your voice a.) turn magically secure, and b.) not be called IP packets.
I didn't bother correcting her as I realized she was just a script-reading monkey making commissions on selling Triple Play. After firmly insisting that no, I really didn't want magic non-VOIP, 'secure', VOIP communication, I asked what the price of basic cable was. I was told it was something like $53 for just basic cable. Note, you cannot find this price on the website, you can only find the price of bundles. I tell her that I know for a fact that people can get cable for $20 or so and she tells me, "oh, you want *limited* cable!, yes that's $20". She then proceeds to tell me that you can either have limited for $20 or what they call the "Digital Starter Pack" for $53. I tell her that Comcast's website says that there is a package in between called "Basic", and she denies it. Perhaps they should fix their (censored) website:
So, at this point she is just lying to me and I know it, so I decide to test her a bit. I ask her about adding internet to the package and bundling the price. She tells me that is the $53 + $43 or $96 a month and that there is no bundle for that. She then mentions that the triple play would be a better deal at $99 with more channels (plus phone!!). I love it when the $8/hr. help tries to treat me like a retarded cave man.
I point out that the a.) the internet is $20/month on the website and b.) internet + cable on the website is only $60 a month there as well. She tells me that it is a special deal only through the web. So, I press the point: "are you telling me that you do not offer a "Double Play" bundle like the website, but you *do* offer the same "Triple Play" bundle as the website? Do you or do you not sell a Double Play option?"
The truth slowly bubbles to the surface. It turns out yes, they do offer a internet + cable bundle called "Double Play" she corrects herself, but it is $70 a month, not $60. I ask her why she told me $96. She tells me she thought I wanted only basic (Digital Starter cable), while the "Double Play" version she sells includes "Digital Preferred" or Premier, I forget. So in essence, she was willing to sell me an inferior package for more money than admit there was a bundle that offered more for less money to prove her point that I should be buying the (censored) Triple Play still. She still won't admit there is a "Basic" cable tier between Limited and Digital Starter either.
I end up telling her that I will order through the website since she can't even sell me the same things that are being offered and she hasn't been entirely forthcoming with me.
Part II: The Installation
After ordering the $60 Double Play bundle including a nice $45 charge to "install" the cable, I confirm online that I want the HD equipment and 2 boxes for my two HD capable TVs. The technicians (contractors) show up on Saturday (1 week ago) and guess what they don't bring? If you said HD boxes... you're right!
After calling support while the contractors were there, the support rep tells me that she will add the HD equipment to the account and that she will call me back. I tell her I want the fee waived since the install is botched - she agrees to waive the fee (yeah!). Guess what happens? If you said, "she won't add the boxes and totally will not call you back and will not waive fee"... you're right!
So, after dickering around a bit, I get the contractors to give me an 'extra' HD box they have in their truck and they call and get it added to my account. Then, they tell me that I will have to drive to the store to get another HD box and "later man", they are gone. At no point did they actually test to make sure that I was getting the programming package that I paid for. So, guess what happens? If you said, "Ryan won't get any of the channels he paid for"... you're right!
Part III: The Cleanup
So, after 1 day I notice that I don't have many channels... in fact I have very few channels. I start an online chat to get those turned on. The rep there can't get them on despite "sending a signal to the box". He schedules a technician visit for me. I explicitly ask for three things (I have this in a transcript): a.) my channels turned on, b.) the missing HD equipment with firewire output for my media center, and c.) to waive the service charge since this a botched thing on their part. He agrees on all three things and tells me they will be there tomorrow between 8am and 12pm.
I wake bright and early on Monday in case they decide to show exactly at 8am. I realize of course that if I am ready at 8am they won't show until 12pm, but if I am not ready at 8am you can bet that will be when they show up according to Murphy's Law. Around 11:20am I decide to give Comcast a call to confirm the scheduled visit. Turns out that the previous rep left no notes to why I called and that they were not going to send anyone. One emergency page later, I have a Comcast technician showing up exactly at 12pm. He admits he has no idea why he is there however and asks me what he can do.
The only bright part in this entire story is that technician. He was a nice, competent guy that actually got things done. He determined that they had just botched configuring the box back at the main office. A few phone calls later, my box is turned on and channels are fixed. Next, he happens to have the HD box I need, so he hooks me up there. He apologizes to me and admits that none of this should have happened and that it could all have been easily fixed on the first attempt. All in all, I think I am done with this tragedy.
Part IV: The Lingering Stink
Today, I got my Comcast bill. Guess what? If you guessed that I would be charged not only for the first $45 botched install, plus the second $20 install to fix the first and would be facing a $150 cable bill for < 7 days service... you're right!
So, today I decide to email them through the Comcast website and see what gets resolved. I explain nicely and in detail what has occurred to this point and try to submit. Of course, nowhere does it explain there is a limit to how much you can email (side note, I forgot that most email systems choke up under 4 paragraphs of text these days). So, many shortened revisions later, I try to submit my story for resolution and here is what I get:
My comcastic adventure is just getting better and better. Naturally, I decide to look up "comcastic" to see what the actual definition is:
comcastic (adj.)
1. A blithe attempt to screw consumers. "The comcastic enterprise left few consumers happy with the reduced service higher prices, and hidden charges".
2. Lacking follow through or resolve. "That fat lazy bastard approached his work like he did exercise: with comcastic resolve."
synonyms: see LIARS, UNRELIABLE, CRAPTACULAR, PRISON SEX
Turns out that is was my fault for not checking the dictionary first when I was told that my experience would be "comcastic".
Wednesday, April 09, 2008
I just posted the first version of PhluffyFotos, our SQL Server Data Services (SSDS) sample app to CodePlex. PhluffyFotos is a photo sharing site that allows users to upload photos and metadata (tags, description) to SSDS for storage. As the service gets more features and is updated, the sample will be rev'd as well.
Points of interest that will likely also be blog posts in themselves:
- This sample has a LINQ-to-SSDS provider in it. You will notice we don't use any strings for queries, but rather lambda expressions. I had a lot of fun writing the first version of this and I would expect that there are a few more revisions here to go. Of course, Matt Warren should get a ton of credit here for providing the base implementation.
- This sample also uses a very simplistic ASP.NET Role provider for SSDS. Likely updates here will include encryption and hashing support.
- We have a number of Powershell cmdlets included for managing authorities and containers.
I have many other ideas for this app as time progresses, so you should check back from time to time to see the updates.
In case anyone was wondering about the name: clouds are fluffy... get it?
You need to have SSDS credentials to run this sample. If you don't have credentials yet, you can see an online version until then at http://www.phluffyfotos.com
Even if you don' t have access to SSDS credentials yet, the code is worth taking a look.
Monday, April 07, 2008
I had the chance recently to sit down and interview two of the senior architects on the SQL Server Data Services team. Istvan and Nigel were good sports for the interview (my first for Channel9). Afterwards, of course I thought to myself, "man, I should have asked them X or Y" - however I will be doing more of these types of interviews, so I can redeem myself hopefully. If there is a particular question you would like me to pose to the team, drop me a line and let me know.
Video Link
Monday, March 31, 2008
Are you a Ruby on Rails (RoR) shop? PHP shop? Java shop? Are you a web startup using open source technologies to build your services?
Great news, we have a limited number of seats available for folks like you to get firsthand exposure to our new HTTP-based (SOAP and REST) data service: SQL Server Data Services (SSDS). You will get early access to the service and the chance to influence the service itself.
We are interested in getting some feedback from people like you that don't necessarily use Microsoft technologies. If you can connect using HTTP, you can use SSDS, so there are very few client limitations here.
How to get involved
If you are one of those non-.NET developers that sees value in utility storage and query processing, send me an email to dpesdr (AT) microsoft.com.
In your email, please tell me about your company and about your product where you think SSDS might fit. We will review your email and follow up with more information.
Details
When: April 24-25th, 2008
Where: Microsoft Silicon Valley Campus
Cost
This is a free event but seating is limited - you must have a confirmed reservation to attend this event. Attendees are responsible for any transportation or lodging costs. Microsoft will provide breakfast, lunch, and light snacks during the event. You are responsible for your own dinner expenses.
About SQL Server Data Services
SQL Server Data Services (SSDS) is a highly scalable web facing data storage and query processing utility. Built on robust SQL Server database technology, these services provide high availability and security and support standards-based web protocols and interfaces (SOAP, REST) for rapid provisioning and ease of programming. Businesses can store and access all types of data from birth to archival and sers can access information on any device, from the desktop to a mobile device.
Key Features and Solution Benefits
Application Agility for quick deployment
• Internet standard protocols and Interfaces (REST, SOAP).
• Flexible data model with no schema required.
• Simple text base query model.
• Easy to program to from any programming environment.
On-Demand Scalability
• Easy storage and access. Pay as you grow model.
• Scales as data grows.
• Web services for provisioning, deployment, and monitoring.
Business-Ready SLA
• Built on robust Microsoft SQL Server database and Windows server technologies.
• Store and manage multiple copies of the data for reliability and availability.
• Back up data stored in each data cluster. Geo-redundant data copies to ensure business continuity.
• Secure data access to help provide business confidentiality and privacy.
Thursday, March 13, 2008
Note: The query model is subject to change based on feedback; this is how it stands today. You can pre-register for the beta at the SSDS home page.
Design Decisions
In this post, I am going to cover how the query model works in SQL Server Data Services (SSDS) today and some of the design goals of SSDS in general.
The first thing to understand is that the SSDS team made a conscious decision to start simple and expand functionality later. The reasoning behind this is simple:
- Simple services that lower the bar to get started are easier to adopt. We want to offer the smallest useful feature set that developers can start using to build applications.
- At the same time, we want to make sure that every feature that is available will scale appropriately at internet-level.
As such, the right model is what the team chose: start simple and expose richer and richer functionality as we prove out the scale and developer's need. The team is committed to short (8 week) development cycles that prioritizes the features based on feedback.
The Query Model
Now that I have covered the design decisions, let's take a look at how the query model actually operates. From my last post, you see that I already showed you the syntax that begins the query operation (?q=). What is important to understand is the following:
- The widest scope for any search is the Container.
Well... almost, but I will get to that. To put this another way: you cannot retrieve entity objects today by searching at the authority level. That's right: there is no cross-container search. This might change in the future, but that is how it is today. For developers familiar with LDAP terminology, this roughly equates to a SearchScope.OneLevel operation. The syntax again is:
https://{authority}.data.sitka.microsoft.com/v1/{container}?q={query} It is important to note that there is no trailing forward slash after the container Id in that.
Now, what did I mean by "almost"? If you saw my last post, I showed the following:
https://{authority}.data.sitka.microsoft.com/v1/?q= This would imply query capabilities, right? Well, it turns out that you can query at the Authority level, but you can only query Container objects (not the entities contained in them). Since a Container is a simple entity with only Id and Version today, it is of limited usefulness to query at this level. However, if we were to add customizable metadata support to attach to a Container, then query might become much more interesting (e.g. find all containers where attribute "foo" equals "bar").
Syntax
The SSDS team decided to adopt a LINQ-like syntax that is carried on the query string. It has the basic format of the following:
from e in entities {where clause} select e Only the part inside the {}'s is modifiable*. We can infer the following from this syntax: One, you can perform only simple selects today. There are no joins, group by, ordering, etc. Two, there is no projection today. There is only the return of the complete entity as the entity is both the unit of storage (POST and PUT) as well as the unit of return (GET).
Now, let's inspect the "{where clause}". The syntax here in more detail is:
where {property} {operator} {constant} Property
The '{property}' part of the expression can operate over both system properties (Id, Kind) as well as flexible properties (anything you added). The syntax is slightly different depending on which it is. For example:
e.Kind
e["MyProperty"] In the case of the system properties, we use the dot notation and the name of the system property. The custom flex properties are addressed using the brace [] syntax in a weakly-typed syntax. This makes sense of course as there is no way we could know the syntax of a schema-less entity.
Operator
The operators ({operator}) that are supported are: ==, <, >, >=, <=, !=
Constant
Finally, for the '{constant}', we have just that - a constant. We do not currently support other expressions or other properties here. As an example the following is invalid:
e["Pages"] > e["AvgPages"] while, this would be perfectly valid:
e["Pages"] > 300 The type of the constant is inferred by the syntax. Using the wrong type will net you zero results possibly, so keep this in mind. Here are some simple examples to show how to format the constant:
e["xsi_decimal_type"] > 300
e["xsi_string_type"] != "String"
e["xsi_boolean_type"] == true
e["xsi_dateTime_type"] == DateTime("2008-02-09T07:45:23.855")
e["xsi_base64Binary_type"] == Binary("AB34CD")
e.Kind == "String"
e.Id == "String"
The last point here in this syntax is that we can tie together multiple expressions using the && (AND), || (OR), and ! (NOT) logical operators. Precedence can be set using parentheses ().
Paging
Results are limited to 500 per GET operation. This is an arbitrary number right now, so don't depend on it. The EntitySet that is returned is implicitly ordered by Id, so you would need to perform a simple loop logic to page through larger sets of data. Something to the effect of:
from e in entities where e.Id > "last ID seen" select e Pulling It Together
Since the query is submitted on the querystring of the URL, we need to encode the querystring using a URL encoding function. It is actually easiest to use a UrlTemplate from .NET 3.5 which does all the right things for you.
Here is a properly formatted GET request that you can type into a browser to retrieve a set of entities.
https://dunnry.data.sitka.microsoft.com/v1/books?q=from+e+in+entities+where+e["Pages"]+>+300+&&+e.Kind=="Bookv2"+select+e In this case, I am asking for Entities of the Kind "Bookv2" that have more than 300 (numeric) pages (from "Pages" flex property). Simple, right?
The actual format that is returned is POX today (support for JSON and APP coming). It would look something like this:
<s:EntitySet xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:x="http://www.w3.org/2001/XMLSchema">
<Bookv2>
<s:Id>MyNewBook</s:Id>
<s:Version>1</s:Version>
<Name xsi:type="x:string">My Special Book 423</Name>
<ISBN xsi:type="x:string">ISBN 423</ISBN>
<PublishDate xsi:type="x:dateTime">2008-02-09T07:43:51.13625</PublishDate>
<Pages xsi:type="x:decimal">400</Pages>
</Bookv2>
</s:EntitySet>
The EntitySet tag wraps around one or many (in this case one) XML nodes that are of Kind "Bookv2". As a developer, I need to interpret this XML and read back the results.
The last point here is that this is the entire entity. As a consumer of this service, I need to think about how my entities will be used. Since there is no projection and only a full entity is returned, it may make sense to break apart larger entities with commonly queried properties and leave larger binary properties (and later blobs) in separate entities. You don't want to pay for the transfer cost or the performance hit of transferring multi-MB (or GB) entities when you only want to read a single flex property from it. I envision people will start to make very light and composable entities to deal with this.
To anyone wondering what "Sitka" is in the namespaces or the URI... it is the old code name for SSDS. That will more than likely change with the next refresh.
Limitations Today
The queries are fairly simple. There is no capability for cross-container queries or joins of any type today. There are no group by operators, or order by functionality. There is also no "LIKE", Contains, BeginsWith, or EndsWith functionality.
I have to stress however, that this is a starting point for the SSDS query API, not the final functionality. I will of course update this blog with the new functionality as it rolls into the service. Again, the team decided that it was better to put a simple and approachable service out there today and gather feedback on what works and what doesn't for specific scenarios than to sit back and code a bunch of functionality that might not be necessary or meet the user's needs. I think this was a good decision and there is an amazing variety of applications that you can build using just this API.
* - not quite... turns out you can change the 'e' to anything you like as long as you are consistent in reference, but that hardly counts as changing the query.
Monday, March 10, 2008
My interview of Istvan Cseri is online now from MIX08. Istvan covers why we should care about SSDS and how it would impact developers. Check it out.
Thursday, March 06, 2008
SQL Server Data Services exposes what we call the 'ACE' concept. This stands for Authority, Container, and Entity. These basic concepts are the building blocks with which you build your applications using SSDS.
You will notice that I intentionally switched the order in my blog post title. The reasoning is that I believe it is easier to understand the model when you learn the entity first.
Flexible Entities
At the core of it all is the idea of a flexible entity. SSDS does not impose a schema on the shape of your data. You are free to define whatever attributes you like with the model and choose some simple types to help you query that data later (string, number, boolean, datetime, or byte[]). Consider the following C# class and how it will be represented on the wire (using the REST API).
public class Book
{
public string Name { get; set; }
public string ISBN { get; set; }
public DateTime PublishDate { get; set; }
public int Pages { get; set; }
public byte[] Image { get; set; }
}
In order to store an instance of this Book class, we would need to serialize it on the wire like so (again this is for REST, not SOAP):
<Book xmlns:s="http://schemas.microsoft.com/stratus/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Id>-544629171</s:Id>
<Name xsi:type="x:string">Some Book</Name>
<ISBN xsi:type="x:string">1234567</ISBN>
<PublishDate xsi:type="x:dateTime">2008-03-06T12:56:53.122-08:00</PublishDate>
<Pages xsi:type="x:decimal">350</Pages>
<Image xsi:type="x:base64Binary">CgsMDQ==</Image>
</Book>
A couple of things to notice about this XML - there is an attribute called Id. This is one of the system level attributes that are required. Along with the container and authority ID, this id will form the basis of the unique URI that represents this resource. The other system attributes are Kind and Version. We control the Id and Kind, but the Version is maintained by SSDS (and why we don't need to send it initially). For the REST API, the Kind equates to the root XML element for the entity (in this case Kind is "Book").
Flexible means flexible
I believe that most developers will use SSDS with a strongly-typed backing class like Book. The serialization and subsequent deserialization of the instance is actually up to you as a developer however.
However, nothing forces me to actually use a backing class for this service. It can be helpful for developers to think of the data they store in SSDS in terms of objects or even rows in a database, but that is not the only way to think about it. More accurately, we can think about the data as a sparse property bag.
I can just as easily store another Book object with the following:
<Book xmlns:s="http://schemas.microsoft.com/stratus/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Id>MySpecialBook</s:Id>
<Name xsi:type="x:string">Some Book</Name>
<ISBN xsi:type="x:string">1234567</ISBN>
<PublishDate xsi:type="x:string">January 2008</PublishDate>
</Book>
Notice in this example that I have removed some properties and then changed the PublishDate property type. This is completely legal when using SSDS and no error will occur for different properties on the same Kind. It is up to you as a developer to figure out the shape of the data coming back and deserialize it appropriately.
As you can see, a flexible entity is really about having different shapes to your data (and no schema).
Containers
Containers are collections of entities. We like to say that the container is unit of consistency for our data. It turns out that containers are the broadest domain of a query or search. As such, containers must also contain a complete copy of all the entities within (that is, they must be co-located on the same node). This further means that there must be some practical limit to the size of the container (as measured by space on disk) at some point because we are constrained by physical storage (also memory and CPU to some extent).
We don't have a hard limit at this point except to say it must exist, but eventually if your container gets big enough, you should consider partitioning it for resource efficiency reasons.
Because containers are another type of entity (albeit a somewhat special one), they also have the system attribute Id. If we look at what a container looks like, you will see that it is a simple XML structure with no custom properties (though that could change).
<s:Container xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:x="http://www.w3.org/2001/XMLSchema">
<s:Id>Books</s:Id>
<s:Version>1</s:Version>
</s:Container>
In this case, the container here is called "Books". The Version attribute comes back from SSDS to tell me what version of the entity I am looking at. It can be used for simple concurrency (more on that in another post).
Authority
Finally, we have the idea of an authority. This is a collection of containers co-located in a specific datacenter today (though this might not always remain true). The authority is analogous to a namespace for .NET developers in a sense as it scopes the containers within it. There is a DNS name attached to the authority that we use when we address a resource using REST. This DNS name is provisioned for a particular user and added to a subdomain off the main SSDS domain name.
Pulling it together
Now that we have covered what ACE means, let's pull it together and see how it affects our URI that we build to address a resource.
https://{authority}.data.sitka.microsoft.com/v1/{containerID}/{entityID}
This build a stable URI for us given an authority name, container Id, and entity Id.
I don't always need all three identifiers in order to address a resource. I can actually query to find resources. For instance, I will query the contents of an authority (the containers), if I target the authority with a GET request:
https://{authority}.data.sitka.microsoft.com/v1/?q=
More commonly, I can query the contents of a container (the entities) by targeting the container URI with a GET request:
https://{authority}.data.sitka.microsoft.com/v1/{containerID}?q=
In this model, you will notice the ?q= portion of the URI. This is the indicator that we want a query. I am not specifying one here, so it acts more like a SELECT *. In a later post, I will cover the query model in more detail.
Wednesday, March 05, 2008
Finally! I can start to talk what I have been working on for the last three months. Today, Ray Ozzie announced the release of SQL Server Data Services (SSDS). SSDS is our cloud-based data storage and processing service. Exposed over HTTP endpoints (REST or SOAP), SSDS delivers your data anywhere in a pay-as-you-go manner. Fundamentally different than other storage services available today is the fact that SSDS is built on the SQL platform. This allows us over time to expose richer and richer capabilities of the underlying platform. Today, we have a set of simple query capabilities that allow us to still build quite sophisticated applications in 'scale-free' manner.
Over the coming weeks and months, I will be blogging more about the shape of the service as well as introducing some very cool samples that show off the power of SSDS.
For more SSDS coverage, checkout the SSDS Team Blog as well.
MIX Sessions
If you are attending MIX08, Nigel Ellis will be delivering a session on SSDS on Thursday at 8:30am in the Delfino 4005 Room. Session recording as well as slides will be available within 24 hours at http://sessions.visitmix.com.
Additionally, we will have a few Open Space sessions available for more information:
- Thursday 12pm – Soumitra Sengupta will talk about the business value of SSDS at Area 1 of Open Space.
- Thursday 2pm – Jeff Currier and Jason Hunter will talk about developing with SSDS in the Theatre area at Open Space.
- Friday 11:30am – Istvan Cseri will talk about architecting for SSDS at Area 1 of Open Space.
Beta Opportunity
A limited beta for SSDS will be starting soon. If you are interested in participating, I encourage you sign up.