Tuesday, March 25, 2014
Open Source Landscape v2 including more categories
Wow, this turned out to be more involved especially in the CMS area. So much human capital and VC funding went into this. Great that we can all leverage it.
Friday, March 21, 2014
The laws of software
There a a couple of laws the govern software. Let's review some of the most common, starting with my favorite coming from a big company.
Conway's Law
Basically this states that software architecture would mirror organizational boundaries. Not surprisingly so since teams optimize to reduce cross team dependencies. It can however be put to good use. If you want to ensure good boundaries in your architecture, mirror those in your organization. Anecdotally I have seen when client and server are in one team. Amazing how the API's become tailored for a specific client and generality goes out the door.
Moore's Law
Probably the most common, this law has to do with the projected growth in computing. Moore's law states that the number of transistors in CPU's would double every 2 years. This made scaling up very tempting and bought many system and engineers some time. Just add ram and bigger CPU's. Scaling out, FWIW is a much better approach but does require some re-architecting if not done from the get go.
Shannon's Law
Shannon's law covers the speed at which data can be transmitted over a specific medium keeping in mind the signal to noise rate. Hard to imagine this law having an impact in the era of 10 Gig-E networks, but does impact wireless and other transmission protocols.
Little's Law
Little's law has application in designing concurrent systems and the relationship between latency and throughput whether a message queue, thread pool or web server. Simple states that the concurrent processing is a function of the incoming transaction rate multiplied with the processing time for every transaction. Example, assuming a consistent web page visit, if you page loads times go up, the CPU usage goes up, which can increase the page load time...you get the idea.
Conway's Law
Basically this states that software architecture would mirror organizational boundaries. Not surprisingly so since teams optimize to reduce cross team dependencies. It can however be put to good use. If you want to ensure good boundaries in your architecture, mirror those in your organization. Anecdotally I have seen when client and server are in one team. Amazing how the API's become tailored for a specific client and generality goes out the door.
Moore's Law
Probably the most common, this law has to do with the projected growth in computing. Moore's law states that the number of transistors in CPU's would double every 2 years. This made scaling up very tempting and bought many system and engineers some time. Just add ram and bigger CPU's. Scaling out, FWIW is a much better approach but does require some re-architecting if not done from the get go.
Shannon's Law
Shannon's law covers the speed at which data can be transmitted over a specific medium keeping in mind the signal to noise rate. Hard to imagine this law having an impact in the era of 10 Gig-E networks, but does impact wireless and other transmission protocols.
Little's Law
Little's law has application in designing concurrent systems and the relationship between latency and throughput whether a message queue, thread pool or web server. Simple states that the concurrent processing is a function of the incoming transaction rate multiplied with the processing time for every transaction. Example, assuming a consistent web page visit, if you page loads times go up, the CPU usage goes up, which can increase the page load time...you get the idea.
Monday, March 17, 2014
Open Source Technology Landscape
Having benefited immensely from LUMA partners version of the advertising landscape, I decided to create one to map out the open source technologies/projects. Not intended to be comprehensive, but do let me know if I missed key projects. Please opine.
Thursday, March 13, 2014
Architecture Tenets
Over my career working in the online / distributed software arena, I have honed in on the following architecture tenets that I tried to deploy in any internet scale architecture problem.
Separation of Concerns
Build autonomous, decoupled services - SOA
Don’t rely purely on Moore’s law. Systems should be decoupled and/or partitioned to scale out
Changes are the norm not the exception
Complicated designs fail in complicated and expensive ways
Failures are the norm not the exception
Separation of Concerns
Build autonomous, decoupled services - SOA
- Define Clear contracts (Semantic, SLA)
- Define Explicit boundaries
- Backward & Forward Compatibility
- Versioning
Don’t rely purely on Moore’s law. Systems should be decoupled and/or partitioned to scale out
- No Single Choke points
- Partitioning should be Fine grained
- Be able to run on Commodity Hardware
- Designed for GEO readiness
Changes are the norm not the exception
- Design applications to be modular and extensible
- Design components to be flexible and configurable
Complicated designs fail in complicated and expensive ways
- Simplified Operability (Instrumentation/Monitoring/Tools)
- Simplified Debugging (Root Cause Analysis)
- Simplified Ramp up
- Diagnostic Capabilities
Failures are the norm not the exception
- No Single Point of Failure
- Services should be resilient (Run in the wild)
- Graceful Degradation of services
- Deployments should be automatable
- Ability to roll back releases
Friday, June 09, 2006
WS-?????
Quite a few standards exist that are used in the SOA arena. Here is a brief summary of the most common and pervasive.
Security with WS-Security
Security can be grouped into 3 types, MLS (Message level security), TLS (Transport level security) and Mixed.
MLS refers to when the message itself is secure. Real world example would be a document in a FedEx envelope that is sealed. TLS refers to making the transport secure, so perhaps the FedEx truck is locked, but if I was to get inside the truck, I could find and potentially read the document.
MLS usually involves data integrity, aka, how do we know the letter was not altered and data confidentiality, how do we know the data is not readable by unauthorized readers.
For the later we utilize encryption xml-Enc whereas for the former we using xml-DSig or digital signatures. Digital signatures are when you create a message digest, or a hash of the content you choose to sign and then encrypt this hash with a shared secret key.
To verify integrity, the reader can create the same hash, encrypt with the shared secret and then compare the signatures. If they don't match the message was tampered.
TLS is the common network security, either using HTTP with SSL or using HTTP authentication protocols, basic etc. TLS is generally faster since we don't have the computing overhead of signing the messages, but are not as secure as MLS especially in multi-hop and/or routing scenarios. (TLS only establishes a node-2-node secure channel).
Mixed is when we use a combination of both, so encrypted document inside a secure transport. Many developers choose to use a home-grown authentication scheme (Custom SOAP Headers) in conjunction with TLS.
Distributed transactions with WS-C(AT) or WS-C(BA)
Transactions are defined by the WS-Coordination and Atomic Transactions (AT)or Business Activity (BA). WS-Coordination defines how we enlist in a transaction and acts as the coordinator.
The AT or BA component defines whether we have a ATOMIC transaction so we "block" all participants until we have a ALL PASS, or BA when we have long running transaction and the "blocking" scenario wont work. With BA we opt for a compensation model.
In these cases, we assume success but provide a compensation mechanism so if we do need to roll back, we can manually do so if notified by the coordinator.
More on Reliable Messaging in my next post...
Security with WS-Security
Security can be grouped into 3 types, MLS (Message level security), TLS (Transport level security) and Mixed.
MLS refers to when the message itself is secure. Real world example would be a document in a FedEx envelope that is sealed. TLS refers to making the transport secure, so perhaps the FedEx truck is locked, but if I was to get inside the truck, I could find and potentially read the document.
MLS usually involves data integrity, aka, how do we know the letter was not altered and data confidentiality, how do we know the data is not readable by unauthorized readers.
For the later we utilize encryption xml-Enc whereas for the former we using xml-DSig or digital signatures. Digital signatures are when you create a message digest, or a hash of the content you choose to sign and then encrypt this hash with a shared secret key.
To verify integrity, the reader can create the same hash, encrypt with the shared secret and then compare the signatures. If they don't match the message was tampered.
TLS is the common network security, either using HTTP with SSL or using HTTP authentication protocols, basic etc. TLS is generally faster since we don't have the computing overhead of signing the messages, but are not as secure as MLS especially in multi-hop and/or routing scenarios. (TLS only establishes a node-2-node secure channel).
Mixed is when we use a combination of both, so encrypted document inside a secure transport. Many developers choose to use a home-grown authentication scheme (Custom SOAP Headers) in conjunction with TLS.
Distributed transactions with WS-C(AT) or WS-C(BA)
Transactions are defined by the WS-Coordination and Atomic Transactions (AT)or Business Activity (BA). WS-Coordination defines how we enlist in a transaction and acts as the coordinator.
The AT or BA component defines whether we have a ATOMIC transaction so we "block" all participants until we have a ALL PASS, or BA when we have long running transaction and the "blocking" scenario wont work. With BA we opt for a compensation model.
In these cases, we assume success but provide a compensation mechanism so if we do need to roll back, we can manually do so if notified by the coordinator.
More on Reliable Messaging in my next post...
Sunday, April 16, 2006
Live & learn
Language SyntaxHaving spent an equal amount of my software engineering career in the Java and Microsoft camp, I have had the priviledge to have seen many problems solved in similar ways.
In the presentation tier, there was ASP, which was followed by JSP. JSP provided us the strength of Java in a similar syntax as ASP, freeying us from harcoded HTML in Servlets. Tag libraries were mirrored by Web Controls in the ASP.Net world.
EJB followed MTS to allow scale out scenarions in the Middle Tier. Btw, e
ver wondered why Microsoft did not implement Entity beans? Ask the EJB containers how complex it is to cache data in objects across a cluster, while keeping them in sync with the DB without loosing the performance benefits you were trying to accomplish in the first place :).Under the hood
It is not uncommon for companies to evaluate and leverage learning from the "otherside", and I guess it goes both ways.
But the biggest similarity is in .Net vs J2SE, or CLR vs JVM, Bytecode vs IL, C# vs Java. If comparing the language syntax is not enough, looking under the hood at bytecode and IL, you get the picture. Callvirt or shall we say invokevirtual.
All good, looking forward what the next generation Java would look like, and then the next .Net and so on and so on....
Thursday, April 06, 2006
OOP vs SO
Object Oriented programming has served us well and will continue to do so. In the case of a SOA, this would imply to only inside the edge, the so-called boundary of my service. Once outside the edge, we need to think in terms of messages. Messages, unlike objects don't have methods.
I have seen too many implementations try and send Business Objects over the wire, only to notice that the business rules in the object did not make it across the WSDL. So to de-serialize the BO's and have them contain methods, we need to modify the client proxy and use a shared library so the server and client can refernce the same BO library.
At a first glance this seems like a rocking solution, but we have just violated the very essence of SOA, loosely coupled components.
Another challenge with BO's is inheritance. While WSDL 2.0 does support the notion of inheritance, again we need to move away from the OOP concepts for the edge.
The Java community often refers to DTO, Data Transfer Objects, to describe a object or structure that contains only data fields, no methods. This is the closest analogy I can think of between the messages of the SO world and objects of the OO world.
So suppose we buy of on this idea, how do we provide tranditional BO like experience in the SOA world? The short answer is, we dont. Having said this, I have seen implementations where the client exposes a BO type interface, and have the BO internalize the service proxy to do all the service calls.
So a call to User.Save(), will internally call the coresponding method on the proxy and service. Personally, I would not go this route, as this hides the fact that we are crossing a boundary and developers may not understand all the implications involved with that single statement.
Secondly the definition of the User object lives inside the client app domain. A similar user object may in fact be exposed by the service (WSDL) and generated by the proxy, so we may be duplicating the entity.
My preference is to create a Business Facade layer, wrapped around the proxies. Instead of calling User.Save(), we would call UserFacade.Save(aUserDTO), or UserDTO user = UserFacade.FetchUser(userId) etc. Hydrating the UserDTO and passing it to the Save method, just seems more aligned to the fact that a message is constructed and will be passed over the wire. I most cases the UserDTO may be the very object generated of the service WSDL.
Boundaries need to be explicit and developers should not be shielded, in constrast with DCOM, of the implications of network latency, out-of-process execution etc.
Having this extra layer of indirection allows us to swap out services, without impacting the rest of my client code.
OOP still has a huge role to play inside the edge, but we need to learn to think in terms of message when we are sending packets of information across our SOA.
I have seen too many implementations try and send Business Objects over the wire, only to notice that the business rules in the object did not make it across the WSDL. So to de-serialize the BO's and have them contain methods, we need to modify the client proxy and use a shared library so the server and client can refernce the same BO library.
At a first glance this seems like a rocking solution, but we have just violated the very essence of SOA, loosely coupled components.
Another challenge with BO's is inheritance. While WSDL 2.0 does support the notion of inheritance, again we need to move away from the OOP concepts for the edge.
The Java community often refers to DTO, Data Transfer Objects, to describe a object or structure that contains only data fields, no methods. This is the closest analogy I can think of between the messages of the SO world and objects of the OO world.
So suppose we buy of on this idea, how do we provide tranditional BO like experience in the SOA world? The short answer is, we dont. Having said this, I have seen implementations where the client exposes a BO type interface, and have the BO internalize the service proxy to do all the service calls.
So a call to User.Save(), will internally call the coresponding method on the proxy and service. Personally, I would not go this route, as this hides the fact that we are crossing a boundary and developers may not understand all the implications involved with that single statement.
Secondly the definition of the User object lives inside the client app domain. A similar user object may in fact be exposed by the service (WSDL) and generated by the proxy, so we may be duplicating the entity.
My preference is to create a Business Facade layer, wrapped around the proxies. Instead of calling User.Save(), we would call UserFacade.Save(aUserDTO), or UserDTO user = UserFacade.FetchUser(userId) etc. Hydrating the UserDTO and passing it to the Save method, just seems more aligned to the fact that a message is constructed and will be passed over the wire. I most cases the UserDTO may be the very object generated of the service WSDL.
Boundaries need to be explicit and developers should not be shielded, in constrast with DCOM, of the implications of network latency, out-of-process execution etc.
Having this extra layer of indirection allows us to swap out services, without impacting the rest of my client code.
OOP still has a huge role to play inside the edge, but we need to learn to think in terms of message when we are sending packets of information across our SOA.
And so it starts...
Finally I have entered the realm of the 21st century media, Blogging. I never was one for giving my opinion unless solicited, but hell, why not. This gives me an opportunity to improve my English.
As I am sure you can tell from the title of my Blog, I am passionate about SOA or (Service Oriented Architecture). If only I had the faintest idea what SOA really was....
My mission with this blog is to discover SOA with my audience (self + 1) and hopefully before too long, be able to crisply articulate SOA and how it will make your business more agile, extensible and ready for change.
To be honest, I have dabbled in the SOA space, and my current project involves migrating from a monolithic service based application, to a SOA. O yes, btw, the mere presence of web services does not imply SOA, nor does a SOA require web services. I have seen web services been used as a new transport, without any architectural changes, which is oddly enough the worst scenario, as SOA by the nature of the transport, SOAP(XML) is probably the most bloated wire payload.
But having delt with the worst of SOA, e.g, not the fasted distributed architecture on the block, tapping the benefits is an easy task. In my next posting, I will attempt to explain where SOA fits into the OOP model we all have come to know and love, and when to let go of OOP. Think in messages....
As I am sure you can tell from the title of my Blog, I am passionate about SOA or (Service Oriented Architecture). If only I had the faintest idea what SOA really was....
My mission with this blog is to discover SOA with my audience (self + 1) and hopefully before too long, be able to crisply articulate SOA and how it will make your business more agile, extensible and ready for change.
To be honest, I have dabbled in the SOA space, and my current project involves migrating from a monolithic service based application, to a SOA. O yes, btw, the mere presence of web services does not imply SOA, nor does a SOA require web services. I have seen web services been used as a new transport, without any architectural changes, which is oddly enough the worst scenario, as SOA by the nature of the transport, SOAP(XML) is probably the most bloated wire payload.
But having delt with the worst of SOA, e.g, not the fasted distributed architecture on the block, tapping the benefits is an easy task. In my next posting, I will attempt to explain where SOA fits into the OOP model we all have come to know and love, and when to let go of OOP. Think in messages....
Subscribe to:
Posts (Atom)