I just realized that although I’ve been working on this book for a while now, I have not yet blogged about it. So, here goes!
I’m writing a book !!!! The title of the book is the same as this blog post, and it is targeted to be published by Apress in the October 2010 timeframe!!!
http://www.apress.com/book/view/1430231114 – here are the details, and here is a picture of the cover:
One of the things that motivated me to write this book was that I was going through a period of time with consulting projects where I seemed to be doing a lot of blended ASP.NET and SharePoint development. While I searched around for different best practices documentation, guidance, examples, and advice on how to integrate a larger ASP.NET application with SharePoint, I really did not find a lot out there. Now there is quite an abundant supply of this on the general SharePoint product, doing customizations on the SharePoint product, Administering SharePoint, and even Content Management. However, the most I could find on what I was doing was one TechNet article, not very long, and one podcast.
So, much of what I had to do on these projects was to experiment and learn all by myself. I also have had a great SharePoint community around us locally to help out with bouncing ideas off of (www.cospug.com ), and a work environment that encouraged me to push ahead with what I was discovering.
So the result of all this was to begin to more formally write up that which I have been discovering with respect to blended ASP.NET and SharePoint solutions, prove the discoveries out in a SharePoint 2010 environment, and convince some high quality acquisitions editors over at APress that the topic was one that had a market space for it.
This book consists of things that I wish I knew when starting to craft solutions using SharePoint’s rich feature set in conjunction with a centric ASP.NET application. It is also targeted towards a crossover market of developers who have experience with ASP.NET but have not yet touched SharePoint deeply. I believe that as the rich feature set present in SharePoint 2010 starts to shine in production environments, this scenario will become more and more common – that corporate developers, consultants, and companies developing software products and solutions will be called upon more and more to integrate with SharePoint 2010. And I’m hoping in some small way to help out this group of people with information, guidance, and a package of information that will help them to integrate this great product in to their solutions in software, and to do it in a way that is supportable, best practices, and sustainable.
So, stay tuned for the book publication. And in the meanwhile, as I figure out a balanced way to do so, I am going to be including some content on my blog – APress actually has a fantastic clause in their author contracts to allow you to do this.
And if you have comments, suggestions, ideas, please shoot them my way!
Dave Milner
One topic that comes up frequently with respect to capacity planning is the consideration for virtualizing one or more farm servers.
Technet has a Virtualization Planning page for SharePoint Server 2010 that is a good starting point for this.
Some basic considerations for virtualization in SharePoint 2010 include:
Also of interest in planning Hyper-V is the Hyper-V Planning and Deployment Guide. While not specific to SharePoint 2010 recommendations, the underlying understanding and recommendations are great to be aware of in architecture design.
MOSS 2007 / WSS 3 had a SharePoint Capacity Planning Tool to assist in planning capacity for a web farm and installation. However, in SharePoint 2010 this tool has been deprecated.
I have been looking around for guidance as to what might take the place of this tool for SharePoint 2010 installations.
What I have found is there are a series of White Papers that Microsoft has published that are a good head start on capacity planning.
The first link is one to the SharePoint Server 2010 performance and capacity test results and recommendations. These are 9 documents that consist of laboratory setups and studies on SharePoint running in different configurations. In one sense these are actually more helpful than the capacity planning tool in that there are real concrete numbers you can attach to recommendations, and they are for specific areas of the SharePoint product as well, such as Access Services, interacting with large lists, InfoPath, PerformancePoint, Search, Workflow and others.
One of the initially most helpful for me was the Divisional PortalCapacityPlanning.docx. This document examines a typical multiple portal intranet setup. It uses 4 server farm configurations – 1x1, 1x1x1, 2x1x1, and 3x1x1 with respect to capacity planning under load. It gives specific hardware configurations for each of the servers, and the hardware configurations seem to be relatively standard in the industry, such as a for the WFE’s a Dell PE 2650 with 2 Quad Core 2.33Ghz processors and 8GB RAM.
One other helpful element is that the test scenario is limited to a typical Intranet environment and does not have all of the add-on services configured that could skew results. For each of the services they did a separate test set up and reported a separate result in another white paper.
Some other helpful information in the document is the construct of the load test itself. The test represents a transactional mix of user activity that while it may not be completely representative of a particular environment does seem to represent a balanced use of different areas of the SharePoint product.
And the reporting results are good too – there are zones represented, like the “Green Zone” meaning that the server is operating within functional service limits. There are also concrete numbers that help out as well, such as the numbers of Requests Per Second (RPS) that each of the configurations can handle.
And there are real concrete results to report as well, backed up by the numbers. For example, did you know that a 1x1x1 farm - (1 WFE, 1 App, and 1 SQL) can support a Green Zone number of 99 requests per second (RPS) or approximately 7000 users in the above configuration? Or a 2x1x1 can support 191 RPS and approximately 13000 users? Or a 3x1x1 can support 242 RPS and approximately 17000 users?
Or how about did you know that a 1x1 farm configuration is not really recommended for standard scenarios? And that in a 1x1x1 AND the 2x1x1 setups the WFE servers are the bottleneck and it is not until you get to the 3x1x1 setups that the SQL Server disk I/O becomes the bottleneck?
Pretty cool stuff, if you ask me. Some supportable data for our recommendations when we are out there helping users set up and configure SharePoint 2010.
Happy capacity planning!!!
Dave
PS – Other white papers also can be found at Technet under Performance and capacity technical case studies
Also, another great resource is the Technet Capacity Management For SharePoint Server 2010 page
Just a post to highlight my presentation tonight for SouthColorado.NET User Group – I'm speaking on an "Introduction to SharePoint for .NET Developers". See www.southcolorado.net for details. The two communities (SharePoint & .NET Dev) seem to be separate. While some of that is certainly specialty focus, my feelings are that the two groups have a lot more in common than not. The development platform in the .NET arena is rapidly expanding to demand collaborative data sources and platforms. Blogs, Twitter, Facebook, LinkedIn, MySpace, forums are all the information stores of 2009+. .NET skills are expanding to a wider environment than ever.
All right, to start out with I have to admit that although my day-to-day career is very much in the applied science software development area, my background in my undergrad work is in Math – totally a pure science. This means that I tend to think in more of a pure model approach as opposed to inherently accepting applied models. This has its pluses and minuses at times, but we all work with what we have.
I was thinking recently “Why the success of SharePoint in the enterprise?”. Of course all the standard arguments of Enterprise 2.0, collaborative environments, information sharing surfaced as an answer. But as I am delving into the software development aspects of SharePoint 2010 and starting to see a little deeper into the platform, I’m starting to realize a more basic reason.
In reality, I think one of the major contributing factors to the success of SharePoint in the enterprise as a platform has to do with how poor the user interface paradigm of a file system really is. Now this is taking a lot of reflection, because I trace my beginnings back to Fortran 4 and being a so-called BSD Unix hacker in the 80’s and early 90’s. So in other words, directories and files are ingrained pretty deeply in my “taken for granted” psyche. When you think about it, from a user’s perspective a filing system such as the one they use or have used in the past for paper looks like this:
Note the external enclosure with clean lines, the drawers, the ability to place decorations on top of it to facilitate good feng shui. To access information in a filing cabinet, you need to physically approach it, pull out a drawer, and then start to look for the particular document you desire. 95% of all filing cabinets have folders organized in an alphabetical order, so you know what to expect. Some of the other 5% and later filing systems would organize cabinets or sections of cabinets into different purposes, like “day to day” or “long term”.
Now a “filing system” on a computer looks and acts much differently than the above. It looks like this:
I think after the 4998765555th time of helping someone not very computer literate find the document they were working on and saved but didn’t know where they saved it to and couldn’t quite get the picture that they might have saved it so someplace different than “My Documents” it started to dawn on me that this whole “file system” paradigm really wasn’t a very good one at all. When you think about it a file system on a computer is the simplest way that “developers” could organize a pointer in memory to a location – by using a string. The forward slashes in a string are a “developer’s” organizational construct, not an intuitive one.
This relates in my mind to some different books I’ve read on the topic of HCI or Human-Computer Interaction and the interrelated field of “UX”. A couple of the first books I read were “The Inmates Are Running the Asylum” and “About Face” by Alan Cooper, which I purchased shortly after being at an architecture conference and having lunch with Alan and about 6 other known tech industry leaders with Alan being on a soapbox about how developers cannot design user interaction because they think differently than end users. Alan’s known as the “Father of Visual Basic” as he designed the first UI interface for Basic that he sold to Microsoft.
So to bring these thoughts and this discussion full circle, I think one of the successes of SharePoint in the enterprise has to do with the fact that a large number of information workers in your enterprise environment are not developer types, and to successfully interact with computers they need paradigms that they can relate to. Most users are familiar enough with the Internet by this point that navigating to a website to procure information is not that foreign at all to them. So if they can browse to a “HR” website, or a “Finance” website they have a head start on finding their document. But a “shared drive”? Not so much. I think organizing information content through a web interface is a UX paradigm that is slightly better than a file system. I think your average information worker “gets this” a little better than a file system. So in my opinion, that is one core fundamental reason that SharePoint has in starting to tie together the enterprise. Network shared drives that are maintained by departments are starting to be replaced with SharePoint document libraries and team sites.
Now maybe you might say that I have too narrow of a view of the skills of an information worker, and that power users or anyone that has used a computer successfully understands the file system. I would respond that first my viewpoints on this have been developed over many years of watching and helping people interact with computer systems and software, and second that a UX paradigm that is “natural” or “intuitive” helps UX flow and facilitates interaction much more than any paradigm that presents an obstacle.
Until next time, happy UX and SharePoint design and development!
I just learned that Channel9 has put up a new site for a SharePoint Learning Center for SharePoint 2010. A number of people are responsible for this, including Paul Stubbs, Girish Raja, Steve Fox, Donovan Follette, and Chris Mayo. It looks to be a video based course center with topics on SharePoint 2010 like:
The SharePoint community and Microsoft is rolling out well ahead of the SharePoint 2010 beta release a number of resources to help developers come up to speed quickly on SharePoint 2010.
For the Channel 9 site, they are first rolling out video examples of all of these sessions and then in about a week or 2 after the beta is released they will release labs with updated code that is compliant with the beta release.
Of course starting to blog about a journey in SharePoint or a re-focus to that product really drives blogging about experiences and things from the ground up. What I've found is that while a couple books walk you through setting up a SharePoint dev environment, and one or two blog posts I've seen out there do the same thing, there are several very basic things that are usually either assumed, implied, or buried 30 feet into the middle of a chapter or post. So I'm going to focus on answering basic practical questions that I had first. In going through this I've developed some opinionated answers, which as my style is I will present with colorful mind pictures.
Q. What Operating System do I need for SharePoint development?
A. People will say you can either do SharePoint development from Visual Studio on any O/S, or to do the development in a server type environment. They are huffing glue. While it is possible to do development for SharePoint in Visual Studio 2008 installed on Windows XP, or Windows 7, or Vista 64 bit, if you do so you will be crawling like a turtle through coding, testing, deploying, testing, etc. You will be slower than a 90 year old who hasn't quite yet had their driver's license revoked. You'll be working at the pace of molasses on the North Slope, Alaska on a cold December morning. You get the point. For any kind of reasonable development pace, you will need to develop on Windows Server 2003 (or stay tuned because SharePoint 2010 will facilitate Windows Server 2008). You need to have pertinent libraries handy, be able to debug, and to deploy to an environment you see the result in a timely fashion. This doesn't happen outside of a server setup for SharePoint development.
Q. OK – I'm going to go with Windows Server 2003 / 8. What else do I need installed?
A. SharePoint 2007, Microsoft Office, SQL Server 2005, Visual Studio 2008 SP1, updates. Don't bother installing the SharePoint SDK or those VSeWSS12 / 13 templates. They don't work very well. Install WSPBuilder for deployment tools from Codeplex. This is not an easy answer to put up with, because it goes against the grain. It takes too !@#$ long to do all those installs just for one stupid dev box. Suck it up, Eggbert, and do the installs. It takes less time to do it right once than wrong three times, and don't ask me how I know. Also you can customize your environment for all the cool little tools you know you always need – like Fiddler, IE Dev Toolbar, SPDisposeCheck, etc.
Q. What about Virtual PC 2007 and using Virtual Machines?
A. Yes, absolutely. They run pretty well from my experience with most of what you're doing in SharePoint. Also, if you keep a copy of your .vhd's every step of the way after building servers (after OS install, after MOSS install, etc.) you can save yourself some duhhhh time. Again, don't ask me how I know. You can also in theory download VM's for SharePoint from Microsoft. I say in theory because they are in 7 parts at over 800MB each and not on MSDN, so you can't use the File Transfer tool. Then you have to piece them together. And it's an eval license on SharePoint so it expires. All those hurdles pointed me towards just building one good MOSS development environment and then backing up the .vhd.
Q. How much space do I need to allocate for the hard drive for my Virtual Machine?
A. My fully loaded dev VM has a VHD that is 14.3GB. This information is nowhere else on the web that I could find. I found it through trial and error. After allocating VHD's of 5GB, 10GB, 40GB, and 20GB. Also after purchasing 2 8GB USB keys which are worthless for SharePoint. Yes a 16GB USB key is plenty to store one good copy of your dev environment Virtual Machine. I don't have info for this yet on the 2010 environment, but I'm going to start testing it at 16GB, and if it doesn't work, try 20GB. A good sturdy external USB hard drive is a good thing to have for storing all these. If you've never been a big fan of virtual machines before, believe me you will be now.
Q. How much RAM does my Virtual Machine need?
A. If you can spare 2GB, by all means do it. If you're RAM challenged (is that an underprivileged class?) than you can squeak by with 1GB, and depending on your box it may not be too slow. If you have the option, get the most RAM you can handle on a machine. If this means a custom order for a laptop with 16GB RAM and Windows Server 2008 as your OS, go for it. You know you want to anyway just to look cool at user's groups and conferences. And put a custom sticker of Wolverine from an old comic release on it too, just to stand out.
Q. These .vhd files have the same extension as the ones I see on Windows Server 2008 in Hyper-V. Can I use my Virtual PC .vhd's on a Hyper-V server?
A. Yes you can, Captain America. What a great excuse to upgrade your dev and test front end servers to Hyper-V.
After thinking about it for quite a while, I've decided to change the direction in which I am going to pursue blogging. Previously, with 3 Degrees of .NET, the blog served more as an information collection and link list type of service. However, with the rise of other social media such as Twitter, this purpose has become obsolete.
Also, I've been more recently focusing in my development on SharePoint, WSS 3.0 and MOSS2007. So I am going to migrate the content of my blog over towards my learning journey in SharePoint. With the product positioning, I'm right on the tail end of an old product and right on the verge of a new product. MOSS is going away, and Microsoft SharePoint 2010 is the official new product, as highlighted here in a note from Tom Rizzo: http://blogs.msdn.com/sharepoint/archive/2009/04/14/microsoft-sharepoint-14-is-now-microsoft-sharepoint-2010.aspx