Based on this post , for a company with 1000 users, to prevent users from creating Groups, Microsoft will charge AUD 91700 ( around USD 72000) per year!
So, is this the extra cost of "cloud platform"? How many of this kind of licensing changes are there waiting for us?!
I am speechless now. :-(
[reference]
Azure Active Directory pricing
https://azure.microsoft.com/en-au/pricing/details/active-directory/
The Price of Office 365 Groups
"I honestly cannot come up with a justification for charging extra for the ability to prevent Groups from being created by every user in your organization."
https://practical365.com/blog/price-office-365-groups/
Showing posts with label Cloud. Show all posts
Showing posts with label Cloud. Show all posts
Tuesday, October 17, 2017
Monday, October 16, 2017
Some thoughts about Microsoft FLOW
After watching Deep dive: Advanced workflow automation with Microsoft Flow, I have to admit that FLOW is much more powerful than I thought. It can replace SharePoint workflows in most of the cases!
However, as it is designed for power users, I smelled something bad.
1. Now I start to understand that why "everyone needs to learn coding". Simple coding(or drag and drop style software development) allows users to do much more work efficiently.
2. We will get millions of worst "software programmers" to build billions of FLOW modules. These FLOW modules may run very slow, may consume a lot of hardware resource, and almost no one can maintain them. Because these FLOW modules are running in Azure, clients need to pay much higher fee than normal. (Microsoft will be very happy about that, and we cannot blame Microsoft)
3. No user would write document for the FLOW functionalities they build.
4. Fix/improve those FLOW modules is not easy, and troubleshooting on those modules would be nightmare.
5. Who is going to test the FLOW modules built by users? A module may accidentally delete a lot of data (which may not be able of recovering), or send out thousands of emails.
6. For most of the FLOW functionalities, if a developer can do it through C# in one day, he/she may need 3 days to do it through "drag and drop". And it's pretty hard to maintain those functionalities. It would take much more time to make minor changes.
7. Not sure how many security issues it will cause if we allow users to build their own FLOW modules.
8. If Microsoft decides to change/upgrade/obsolete some API/function, who is going to upgrade existing customized FLOW modules?
Conclusion: FLOW is too powerful, so it is not for power users but for developers. Normal power users can use it, but only for very simple functionality, especially when some system other than SharePoint is involved. Only in those cases, FLOW is useful to power users and can improve productivity.
However, as it is designed for power users, I smelled something bad.
1. Now I start to understand that why "everyone needs to learn coding". Simple coding(or drag and drop style software development) allows users to do much more work efficiently.
2. We will get millions of worst "software programmers" to build billions of FLOW modules. These FLOW modules may run very slow, may consume a lot of hardware resource, and almost no one can maintain them. Because these FLOW modules are running in Azure, clients need to pay much higher fee than normal. (Microsoft will be very happy about that, and we cannot blame Microsoft)
3. No user would write document for the FLOW functionalities they build.
4. Fix/improve those FLOW modules is not easy, and troubleshooting on those modules would be nightmare.
5. Who is going to test the FLOW modules built by users? A module may accidentally delete a lot of data (which may not be able of recovering), or send out thousands of emails.
6. For most of the FLOW functionalities, if a developer can do it through C# in one day, he/she may need 3 days to do it through "drag and drop". And it's pretty hard to maintain those functionalities. It would take much more time to make minor changes.
7. Not sure how many security issues it will cause if we allow users to build their own FLOW modules.
8. If Microsoft decides to change/upgrade/obsolete some API/function, who is going to upgrade existing customized FLOW modules?
Conclusion: FLOW is too powerful, so it is not for power users but for developers. Normal power users can use it, but only for very simple functionality, especially when some system other than SharePoint is involved. Only in those cases, FLOW is useful to power users and can improve productivity.
Tuesday, September 19, 2017
PowerShell Runbook to auto start and shut down Azure VM in a resource management group
Last post listed the sample code to start and shut down Azure VM remotely.
Here is the PowerShell runbook script which can be scheduled in Azure.
This is more stable, simpler and easier to manage.
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID `
-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint
Write-Output "Connection established."
$vmname = 'AZ532-test1'
$VMDetail = Get-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Status
$vmPowerstate = $VMDetail[1].Code
Write-Verbose "vmPowerstate: $vmPowerstate"
if ($vmPowerstate -like "PowerState/running"){
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
else{
write-host "Starting VM '$vmname'"
Start-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose
}
Write-Output "VM $vmname is started."
==============
Azure classic VM is similar:
$ConnectionAssetName = "AzureClassicRunAsConnection"
$connection = Get-AutomationConnection -Name $connectionAssetName
Write-Verbose "Get connection asset: $ConnectionAssetName" -Verbose
$Conn = Get-AutomationConnection -Name $ConnectionAssetName
if ($Conn -eq $null)
{
throw "Could not retrieve connection asset: $ConnectionAssetName. Assure that this asset exists in the Automation account."
}
Write-Output "Connection established."
$CertificateAssetName = $Conn.CertificateAssetName
Write-Verbose "Getting the certificate: $CertificateAssetName" -Verbose
$AzureCert = Get-AutomationCertificate -Name $CertificateAssetName
if ($AzureCert -eq $null)
{
throw "Could not retrieve certificate asset: $CertificateAssetName. Assure that this asset exists in the Automation account."
}
Write-Verbose "Authenticating to Azure with certificate." -Verbose
Set-AzureSubscription -SubscriptionName $Conn.SubscriptionName -SubscriptionId $Conn.SubscriptionID -Certificate $AzureCert
Select-AzureSubscription -SubscriptionId $Conn.SubscriptionID
$vmname = 'hvEF4'
$vm = Get-AzureVM | Where-Object { $_.Name -eq $vmname }
write-host "AzureVM: "
$vm | fl *
# if ($vm.PowerState -eq "Started"){
# write-host "Stopping VM '$vmname'"
# $vm | Stop-AzureVM -Force
# }
# else{
# write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
# }
if ($vm.PowerState -eq "Started"){
write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
}
else{
write-host "Starting VM '$vmname'"
$vm | Start-AzureVM
}
write-host "done."
Here is the PowerShell runbook script which can be scheduled in Azure.
This is more stable, simpler and easier to manage.
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID `
-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint
Write-Output "Connection established."
$vmname = 'AZ532-test1'
$VMDetail = Get-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Status
$vmPowerstate = $VMDetail[1].Code
Write-Verbose "vmPowerstate: $vmPowerstate"
if ($vmPowerstate -like "PowerState/running"){
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
else{
write-host "Starting VM '$vmname'"
Start-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose
}
# if ($vmPowerstate -like "PowerState/running"){
# write-host "Stopping VM '$vmname'"
# Stop-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose -Force
# }
# else{
# write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
# }
==============
Azure classic VM is similar:
$ConnectionAssetName = "AzureClassicRunAsConnection"
$connection = Get-AutomationConnection -Name $connectionAssetName
Write-Verbose "Get connection asset: $ConnectionAssetName" -Verbose
$Conn = Get-AutomationConnection -Name $ConnectionAssetName
if ($Conn -eq $null)
{
throw "Could not retrieve connection asset: $ConnectionAssetName. Assure that this asset exists in the Automation account."
}
Write-Output "Connection established."
$CertificateAssetName = $Conn.CertificateAssetName
Write-Verbose "Getting the certificate: $CertificateAssetName" -Verbose
$AzureCert = Get-AutomationCertificate -Name $CertificateAssetName
if ($AzureCert -eq $null)
{
throw "Could not retrieve certificate asset: $CertificateAssetName. Assure that this asset exists in the Automation account."
}
Write-Verbose "Authenticating to Azure with certificate." -Verbose
Set-AzureSubscription -SubscriptionName $Conn.SubscriptionName -SubscriptionId $Conn.SubscriptionID -Certificate $AzureCert
Select-AzureSubscription -SubscriptionId $Conn.SubscriptionID
$vmname = 'hvEF4'
$vm = Get-AzureVM | Where-Object { $_.Name -eq $vmname }
write-host "AzureVM: "
$vm | fl *
# if ($vm.PowerState -eq "Started"){
# write-host "Stopping VM '$vmname'"
# $vm | Stop-AzureVM -Force
# }
# else{
# write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
# }
if ($vm.PowerState -eq "Started"){
write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
}
else{
write-host "Starting VM '$vmname'"
$vm | Start-AzureVM
}
write-host "done."
Thursday, September 14, 2017
PowerShell script sample code to auto start and shut down Azure VM in a resource management group
There are quite a lot of changes in RMVM access API in the last two years. Here is some sample code which works well at the moment (2017-09-14).
Hopefully they can save you some time.
1. Install AzureRM module
script: Install-Module -Name AzureRM
2. Check PowerShell version and AzureRM module version
script: $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
5 1 14393 1715
script: (get-module azurerm).Version
Major Minor Build Revision
----- ----- ----- --------
4 3 1 -1
3. Import AzureRM module
script: Import-Module AzureRM
4. Log in without prompt window
First we need to create a file to store the context information.
Login-AzureRmAccount
$Global:_ContextFilePath = "c:\azure.user.ericfang@outlook.com.ctx"
Save-AzureRmContext -Path $Global:_ContextFilePath -Force
Then we can import the context file to avoid input user name and password manually.
Import-AzureRmContext -Path $Global:_ContextFilePath
if ($vmPowerstate -like "PowerState/running"){
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
else{
write-host "Starting VM '$vmname'"
Start-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose
}
7. Or, shut it down (deallocate it)
if ($vm.PowerState -like "PowerState/running"){
write-host "Stopping VM '$vmname'"
Stop-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose -Force
}
else{
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
Done.
PS: I scheduled the script in windows task scheduler to shut down all dev VMs in the evening. That can save a lot in case I forgot to shut them down manually.
PS 2:
Below is the script to start or stop classic Azure VM.
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1"
# Get-AzurePublishSettingsFile
$publishsettings = 'e:\EricFang\Visual Studio Ultimate with MSDN-9-16-2016-credentials.publishsettings'
write-host "AzureSubscription: "
Import-AzurePublishSettingsFile $publishsettings
Select-AzureSubscription -SubscriptionId "YOUR SUBSCRIPTION GUID STRING"
$vmname = 'hvEF4'
$vm = Get-AzureVM | Where-Object { $_.Name -eq $vmname }
write-host "AzureVM: "
$vm | fl *
if ($vm.PowerState -eq "Started"){
write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
}
else{
write-host "Starting VM '$vmname'"
$vm | Start-AzureVM
}
# $vm | Stop-AzureVM -Force
write-host "done."
Hopefully they can save you some time.
1. Install AzureRM module
script: Install-Module -Name AzureRM
2. Check PowerShell version and AzureRM module version
script: $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
5 1 14393 1715
script: (get-module azurerm).Version
Major Minor Build Revision
----- ----- ----- --------
4 3 1 -1
3. Import AzureRM module
script: Import-Module AzureRM
4. Log in without prompt window
First we need to create a file to store the context information.
Login-AzureRmAccount
$Global:_ContextFilePath = "c:\azure.user.ericfang@outlook.com.ctx"
Save-AzureRmContext -Path $Global:_ContextFilePath -Force
Then we can import the context file to avoid input user name and password manually.
Import-AzureRmContext -Path $Global:_ContextFilePath
5. Get the RM VM
$vmname = 'vm name'
$VMDetail = Get-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $VmName -Status | Select-Object -ExpandProperty StatusesText | convertfrom-json
$vmPowerstate = $VMDetail[1].Code
$VMDetail = Get-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $VmName -Status | Select-Object -ExpandProperty StatusesText | convertfrom-json
$vmPowerstate = $VMDetail[1].Code
6. Start VM
if ($vmPowerstate -like "PowerState/running"){
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
else{
write-host "Starting VM '$vmname'"
Start-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose
}
7. Or, shut it down (deallocate it)
if ($vm.PowerState -like "PowerState/running"){
write-host "Stopping VM '$vmname'"
Stop-AzureRMVM -ResourceGroupName $ResourceGroupName -Name $VmName -Verbose -Force
}
else{
write-host "VM '$vmname' is ""$vmPowerstate"". Skip."
}
Done.
PS: I scheduled the script in windows task scheduler to shut down all dev VMs in the evening. That can save a lot in case I forgot to shut them down manually.
PS 2:
Below is the script to start or stop classic Azure VM.
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1"
# Get-AzurePublishSettingsFile
$publishsettings = 'e:\EricFang\Visual Studio Ultimate with MSDN-9-16-2016-credentials.publishsettings'
write-host "AzureSubscription: "
Import-AzurePublishSettingsFile $publishsettings
Select-AzureSubscription -SubscriptionId "YOUR SUBSCRIPTION GUID STRING"
$vmname = 'hvEF4'
$vm = Get-AzureVM | Where-Object { $_.Name -eq $vmname }
write-host "AzureVM: "
$vm | fl *
if ($vm.PowerState -eq "Started"){
write-host "VM '$vmname' is ""$($vm.PowerState)"". Skip."
}
else{
write-host "Starting VM '$vmname'"
$vm | Start-AzureVM
}
# $vm | Stop-AzureVM -Force
write-host "done."
Friday, May 27, 2016
SharePoint Online - replace Server-side programming with Client-side programming
Finally, with the help of WebHooks, we can use Client-side programming to replace Server-side programming in SharePoint. ( http://www.paitgroup.com/microsoft-renews-its-vows-with-sharepoint/ )
But, does it really resolve the problem of customization on SharePoint Online sites?
In many cases, YES, but we need to be very careful. Because "data communication" is moved from RAM-RAM to Computer-Computer.
1. Hardware Latency
Latency of communication between different processes on the same machine, is totally different from the one between different machines. Let's check it here ( https://gist.github.com/jboner/2841832 ). "Main memory reference" consumes around 100 ns, and "Round trip within same data center" takes around 500 us, which means the latter is 5000 times slower.
For external servers (not in the same data center), "Round trip" may take more than 30 ms. That's 300,000 times slower.
Caching doesn't help much in many cases.
2. Stability
Let's assume that all servers are in the same data center. Is the network in a data center as robust as the RAM on one computer?
3. Extra hardware overhead
How much work it needs to handle a web service request? Please check here for "IIS Architectures" http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture
How much extra CPU, Memory Access, DISK IO, Network IO will be consumed for each request? Do we need to pay for that?
A data center may handle one million concurrent users easily, but, when one user open a customized page, it may cause many HTTP(s) requests by the JavaScript on that page. And, each triggered workflow instance may also submit many HTTP(s) requests!
4. Development and trouble shooting
To move a workflow activity from "Server Object model" to "Client object model", for me, it's painful.
SharePoint 2013 CSOM APIs are powerful, but, because there is one more layer, it's more complex. However, this post suggests to utilize mature third-party APIs instead of "reinventing wheels". I totally don't agree about that, because of "Reliability".
5. Reliability
If everything is on-premise, for a normal middle size enterprise, they may utilize 10,000 APIs(through assemblies) from 20 different software vendors. That's fine. Everything is fully tested before deploying to production servers. Any update/patch will also be fully tested on non-production servers.
But, if there are 10,000 APIs(through Web Services) from 20 different vendors, how can we keep the whole systems stable? If, on average, each API is upgraded/changed every 10 years, then there will be 3 APIs(Web Services) being changed every day. And not likely the changes can get fully tested on non-production environment first.
In general, the quality of Microsoft products is pretty good, but, how many times Microsoft recalled updates of their products? Can we expect the software/service/APIs from those 20 vendors are all as good as the one from Microsoft? How much we need to pay for these APIs every year?
In summary, we can move everything into cloud, just need to be cautious.
But, does it really resolve the problem of customization on SharePoint Online sites?
In many cases, YES, but we need to be very careful. Because "data communication" is moved from RAM-RAM to Computer-Computer.
1. Hardware Latency
Latency of communication between different processes on the same machine, is totally different from the one between different machines. Let's check it here ( https://gist.github.com/jboner/2841832 ). "Main memory reference" consumes around 100 ns, and "Round trip within same data center" takes around 500 us, which means the latter is 5000 times slower.
For external servers (not in the same data center), "Round trip" may take more than 30 ms. That's 300,000 times slower.
Caching doesn't help much in many cases.
2. Stability
Let's assume that all servers are in the same data center. Is the network in a data center as robust as the RAM on one computer?
3. Extra hardware overhead
How much work it needs to handle a web service request? Please check here for "IIS Architectures" http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture
How much extra CPU, Memory Access, DISK IO, Network IO will be consumed for each request? Do we need to pay for that?
A data center may handle one million concurrent users easily, but, when one user open a customized page, it may cause many HTTP(s) requests by the JavaScript on that page. And, each triggered workflow instance may also submit many HTTP(s) requests!
4. Development and trouble shooting
To move a workflow activity from "Server Object model" to "Client object model", for me, it's painful.
SharePoint 2013 CSOM APIs are powerful, but, because there is one more layer, it's more complex. However, this post suggests to utilize mature third-party APIs instead of "reinventing wheels". I totally don't agree about that, because of "Reliability".
5. Reliability
If everything is on-premise, for a normal middle size enterprise, they may utilize 10,000 APIs(through assemblies) from 20 different software vendors. That's fine. Everything is fully tested before deploying to production servers. Any update/patch will also be fully tested on non-production servers.
But, if there are 10,000 APIs(through Web Services) from 20 different vendors, how can we keep the whole systems stable? If, on average, each API is upgraded/changed every 10 years, then there will be 3 APIs(Web Services) being changed every day. And not likely the changes can get fully tested on non-production environment first.
In general, the quality of Microsoft products is pretty good, but, how many times Microsoft recalled updates of their products? Can we expect the software/service/APIs from those 20 vendors are all as good as the one from Microsoft? How much we need to pay for these APIs every year?
In summary, we can move everything into cloud, just need to be cautious.
Sunday, April 6, 2014
Node.js, C# and SharePoint API
Just curious: is Microsoft plan to integrate Node.js features into C# and SharePoint server side API?
I think it's a MUST, at least for SharePoint online.
Don't know whether I am the only one got this issue: when deploying farm solutions to SharePoint Server, it's always slow. I have CPU Intel Core i7 3770, 32GB RAM, two SSD disks (Intel 520 and Samsung 840 Pro). From performance monitor, I can see that there is no performance bottleneck, but it's still slow.
I am not talking about "minutes", but something like "20 seconds". But it makes me confused: if CPU usage and SSD access is less than 1%, then, what make the deployment procedure so slow?
I think it's a MUST, at least for SharePoint online.
Don't know whether I am the only one got this issue: when deploying farm solutions to SharePoint Server, it's always slow. I have CPU Intel Core i7 3770, 32GB RAM, two SSD disks (Intel 520 and Samsung 840 Pro). From performance monitor, I can see that there is no performance bottleneck, but it's still slow.
I am not talking about "minutes", but something like "20 seconds". But it makes me confused: if CPU usage and SSD access is less than 1%, then, what make the deployment procedure so slow?
SharePoint has potential to be much, much faster.
Monday, October 15, 2012
The major barrier of cloud computing
It has been a few years since people started talking about "cloud computing". But it seems not many people think about the problem from business perspective.
As a normal business corporation, what do they need?
Let's say there are 10 systems in a company, some are running on windows, some are running on UNIX or Linux. Of course these systems talk to each other to provide high quality services.
Now, CIO believes it's good timing to move part of them into "cloud". He wants to move 2 systems into Microsoft cloud, 2 systems into Google cloud, 2 systems into Amazon, and leave the rest on-premise servers. (We don't want to put all eggs into one basket, do we?)
How can we achieve that? Technically say, it's no possible (at the moment).
As I know, "OAuth" is becoming the standard user authentication protocol on Internet. So, different clouds are bound to different user profile source, such as Google account, Outlook account, etc. Can I use Google account to access the data stored in Microsoft cloud?
To resolve this problem, as the first step, we need some organization similar to ICANN, but it manages user identity instead of IP address. It can do the user authentication and then issue "user security ticket" to all the clouds on Internet. All data access permissions should be based on that "user identity". Without it, the clouds are isolated from each other.
How long it would take to set up such an organization? I will be surprised if it start to work in 10 years.
Ok, let's go for private cloud. We have our own "domain controller" there, and don't need to worry about this headache.
(Please leave comments here if you have other thoughts.)
[20121016 Update]
People often think "Pay-as-You-Go" is one of the major advantages of cloud computing, so the cloud computing could be treated as "service" instead of "software". However, although we can easily switch service provider in some areas, such as electricity and ISP, can we do the same switch on cloud computing?
If we cannot switch cloud provider, is it really a smart choice to move to cloud computing?
As a normal business corporation, what do they need?
Let's say there are 10 systems in a company, some are running on windows, some are running on UNIX or Linux. Of course these systems talk to each other to provide high quality services.
Now, CIO believes it's good timing to move part of them into "cloud". He wants to move 2 systems into Microsoft cloud, 2 systems into Google cloud, 2 systems into Amazon, and leave the rest on-premise servers. (We don't want to put all eggs into one basket, do we?)
How can we achieve that? Technically say, it's no possible (at the moment).
As I know, "OAuth" is becoming the standard user authentication protocol on Internet. So, different clouds are bound to different user profile source, such as Google account, Outlook account, etc. Can I use Google account to access the data stored in Microsoft cloud?
To resolve this problem, as the first step, we need some organization similar to ICANN, but it manages user identity instead of IP address. It can do the user authentication and then issue "user security ticket" to all the clouds on Internet. All data access permissions should be based on that "user identity". Without it, the clouds are isolated from each other.
How long it would take to set up such an organization? I will be surprised if it start to work in 10 years.
Ok, let's go for private cloud. We have our own "domain controller" there, and don't need to worry about this headache.
(Please leave comments here if you have other thoughts.)
[20121016 Update]
People often think "Pay-as-You-Go" is one of the major advantages of cloud computing, so the cloud computing could be treated as "service" instead of "software". However, although we can easily switch service provider in some areas, such as electricity and ISP, can we do the same switch on cloud computing?
If we cannot switch cloud provider, is it really a smart choice to move to cloud computing?
Saturday, October 6, 2012
SharePoint 2013: Rules are changed
The new features of SharePoint 2013 are not so attractive.
Don't get me wrong. It's an excellent product. Like the post Capabilities and features in SharePoint 2013 states, there are many wonderful improvements. I have no doubt that any company who wants to build their SharePoint platform from scratch, they will choose SharePoint 2013 instead of 2010. However, for those companies already got SharePoint 2010, are they going to upgrade to 2013?
I am a SharePoint administrator and developer in a medium size company. In my opinion, there is no killer change to persuade managers to make up their mind. And, the upgrade will be quite painful(there is even no in-place upgrade)!
Then, if I am right (that most of the companies are not going to upgrade to SharePoint 2013), what should we do as SharePoint professionals?
We need to think in different perspective.
Back to 1998, most of the computer systems are built in C/S structure. I was a junior developer working on windows platform. A IT sales person recommended us to move to multi-tier architecture, and told us it was more stable, more flexible and even more efficient.
I was confused.
If we add one more layer in the middle of the system, then we need to build two more set of interface, and all the data needs to go to the middle layer first, then, after some process, be forwarded to the data layer (database server normally). There would be much more source code, how could it be "more stable, more flexible and even more efficient"?
If there is only one computer system (module) in a company, and no need to change existing features, and no need to interact with any other computer systems of other company, actually, my intuitive thoughts is right: C/S is better. But, if the business logic needs to get changed all the time, and there are five, or even more than ten different systems which need to communicate with each other, we'd better think it again.
Multi-tier architecture is not designed for single small systems. The more systems we have, the more complex the system is, the more pain we will get with C/S structure.
Now, it's 2012. For even medium size enterprise, we may have more than 30 different systems across the country. For large enterprise, I will not be surprised if there are 100+ systems across the world. Is multi-tier architecture still suitable?
That's one of the major reasons that so many people are considering moving to "cloud". For "Cloud computing", what do we need to prepare as IT professionals? Let's imagine this: there are one million different systems in your company.
Of course, we don't have so many systems to support, but that's the situation every cloud hosting company need to handle. From that point of view, it's easy to understand why SharePoint 2013 get separate app server and workflow server. All apps and workflows need web services instead of object model APIs to access other systems. All SharePoint customized are recommended to be moved to app server and workflow server, which can obviously make SharePoint more stable and easier to upgrade to future version.
The separate app server and workflow server, in my opinion, are just like the first stage of "private cloud". Internet connection is still too slow and too expensive. So, private cloud is the only choice in most of cases.
Now, what can we do to get that "private cloud" (in other words, move to SharePoint 2013)?
Here is my suggestion.
1. Build a new farm for SharePoint 2013 (this is something we have to do anyway);
2. Move those site collections which don't have any customization to the new farm;
3. For any new site collection, build them in the new farm;
4. Rebuild existing application sites in the new farm if necessary; or just leave them with the old farm (SharePoint 2010), until they are replaced by other new systems.
5. Stick to apps in the new farm when customization is needed.
To get more details of the hierarchy of SharePoint 2013, I strongly recommend this post: The background on apps for Office and SharePoint
Any thoughts? Please leave comments here.
(I haven't got chance to try apps yet. Plan to write some posts about it.)
Don't get me wrong. It's an excellent product. Like the post Capabilities and features in SharePoint 2013 states, there are many wonderful improvements. I have no doubt that any company who wants to build their SharePoint platform from scratch, they will choose SharePoint 2013 instead of 2010. However, for those companies already got SharePoint 2010, are they going to upgrade to 2013?
I am a SharePoint administrator and developer in a medium size company. In my opinion, there is no killer change to persuade managers to make up their mind. And, the upgrade will be quite painful(there is even no in-place upgrade)!
Then, if I am right (that most of the companies are not going to upgrade to SharePoint 2013), what should we do as SharePoint professionals?
We need to think in different perspective.
Back to 1998, most of the computer systems are built in C/S structure. I was a junior developer working on windows platform. A IT sales person recommended us to move to multi-tier architecture, and told us it was more stable, more flexible and even more efficient.
I was confused.
If we add one more layer in the middle of the system, then we need to build two more set of interface, and all the data needs to go to the middle layer first, then, after some process, be forwarded to the data layer (database server normally). There would be much more source code, how could it be "more stable, more flexible and even more efficient"?
If there is only one computer system (module) in a company, and no need to change existing features, and no need to interact with any other computer systems of other company, actually, my intuitive thoughts is right: C/S is better. But, if the business logic needs to get changed all the time, and there are five, or even more than ten different systems which need to communicate with each other, we'd better think it again.
Multi-tier architecture is not designed for single small systems. The more systems we have, the more complex the system is, the more pain we will get with C/S structure.
Now, it's 2012. For even medium size enterprise, we may have more than 30 different systems across the country. For large enterprise, I will not be surprised if there are 100+ systems across the world. Is multi-tier architecture still suitable?
That's one of the major reasons that so many people are considering moving to "cloud". For "Cloud computing", what do we need to prepare as IT professionals? Let's imagine this: there are one million different systems in your company.
Of course, we don't have so many systems to support, but that's the situation every cloud hosting company need to handle. From that point of view, it's easy to understand why SharePoint 2013 get separate app server and workflow server. All apps and workflows need web services instead of object model APIs to access other systems. All SharePoint customized are recommended to be moved to app server and workflow server, which can obviously make SharePoint more stable and easier to upgrade to future version.
The separate app server and workflow server, in my opinion, are just like the first stage of "private cloud". Internet connection is still too slow and too expensive. So, private cloud is the only choice in most of cases.
Now, what can we do to get that "private cloud" (in other words, move to SharePoint 2013)?
Here is my suggestion.
1. Build a new farm for SharePoint 2013 (this is something we have to do anyway);
2. Move those site collections which don't have any customization to the new farm;
3. For any new site collection, build them in the new farm;
4. Rebuild existing application sites in the new farm if necessary; or just leave them with the old farm (SharePoint 2010), until they are replaced by other new systems.
5. Stick to apps in the new farm when customization is needed.
To get more details of the hierarchy of SharePoint 2013, I strongly recommend this post: The background on apps for Office and SharePoint
Any thoughts? Please leave comments here.
(I haven't got chance to try apps yet. Plan to write some posts about it.)
Subscribe to:
Posts (Atom)