1. I'm here with Mohammed Akif at VS Live in Toronto. Would you introduce yourself and tell us what do?
I'm a Microsoft architect at Microsoft Canada. I'm responsible for providing guidance to our customers and work with them to adopt .NET technologies, especially in the areas of Service Oriented Architecture which I understand we're going to talk about today. Prior to joining Microsoft I was working as a Senior Java architect at Sun Microsystems. I moved over to Microsoft because I wanted to get discounts on Xbox games. Here I am now sitting with you and hoping we could discuss some interesting topics around SOA.
2. SOA, What's behind the hype? What's the real story behind SOA?
In my opinion the hype of SOA is only matched by the confusion that surrounds it. It's interesting that all the marketing that is going on in terms of every IT vendor rebranding their products to become SOA enabled. It is really hard to separate the myth from reality. In this short time that we have, I would like to point out a couple of things I think people should consider while they study SOA and think about implementing it. Number one: the idea of SOA is not new. They're just new words, but in my opinion we're talking about just bigger objects and now you have boundaries and there are some differences and I know we can have an academic debate about whether it is really that; but I really consider it to be an evolution of ideas that have been presented for the last two decades essentially, so in that way it's really an evolution not a revolution. Also I think that one of the key things that we missed in the .com bust was that services or SOAs are not an end, but a means. What you have to make sure while you're considering SOA is really tied back to your business requirements and your business value it is going to provide. Think about this: I want to make it a service but why would I want to do it? Does it make it faster, better, cheaper? I might be able to serve my business users better. In that sense, in terms of being beyond the hype, what you really have to consider is this: what are the business benefits you're going to get and then determine what makes sense for your organisation? Do a crawl/walk/run approach where you start with something small, take some measurements at the start, look at them after the project is implemented and see whether this is something that would be useful. I am a big believer in SOA, it think it would be useful for your organization, but you need to go through the learning process and really identify the areas and projects that could use it now or three years from now.
3. With SOA, when do you go with tight-coupling vs. loose-coupling?
One of the myth-busting truths is that everything must be extremely loosely coupled. We have gone from a world where we believed in really siloed, structured, vertical solutions to something that says "have 400 xml parsings between one request and other" and the happy medium is really think about whether you want to have tight coupling in certain areas because that serves your business need and the fact that it would be harder to maintain doesn't justify the fact that you won't be able to serve your business users if you don't have tight coupling between two objects. On the other hand, in general, you should look at the best possible architecture and that does command that you go with a loosely coupled environment. But again I'm reiterating myself. What you should think about is this: don't add a layer of abstraction just for the sake of it, or for making the picture look cute or better. What you should think about is adding this layer of abstraction now, it does make it more loosely coupled what is the cost and what is the benefit. And then make a decision as to whether makes sense to do it or not.
4. The key thing is not to get too granular with it and keep your services coarse.
Absolutely. One of the key things and unfortunately there's no real guidance so that anybody can provide and say: "this is the line you should draw". Typically you should think about services as black boxes and they should do x amount of things within them, you should really have a very chatty service in which you're doing every method yourself; each method is now a service unless you have a very specific application that typically is not something that you're looking for. Think about it in general terms. Think about the post office. A post office is a service, you go in there, you give an envelope and a stamp and you know the input service that you're giving and know the output that's going to occur; maybe you don't know what's happening in between, but there's a defined sort of interface that you're dealing and there's a defined contract between you and the post office and you can add reliability to it by making it registered etc etc you add a cost to it when you do that and that's how you really should think about services. Think about the business process and think about what are the real atomic portions of the process that you can combine together as services. The last thing I would say: don't go with your intuition. Don't think that just because you feel that's going to be a service, it is really a reusable component. In fact do something like a "voice of customer interviews"; think about it from a business process, think about what are the portions; forget about the technology, look at the business process flow diagram. Here's a portion that we see as literally common across our processes and this is something that would make sense to me as a service. I think that how you draw the boundaries, is one of the most challenging and critical portions of implementing Service Oriented Architecture.
Absolutely. In certain cases it might also prove to be expensive. In general when you have a reusable component, typically it means that the cost of developing that particular component is higher than if you had had it integrated it within the single solution that you have. On the other hand, as the second group or project customers start using it starts making sense in terms of ROI. To your point you should really look at what is the cost that you are going to spend on it and what is the benefit in terms of how many people would be able to reuse it, also one of the different flavours and variations that you need to provide in order to serve your customer base.
One of my focus areas at Microsoft because of my background is interoperability. I want to start with an optimistic statement which says that interoperability is possible; there are huge companies, financial institutions, government, healthcare, telecom, every industry nowadays has interop solutions. Various studies show that a large number of companies do have diverse IT environment and they need to have interop solutions. First of all it is possible, it is happening; large critical systems have been implemented on solutions that are based on interoperability. Having said that, coming to your point now which is that the promise of interoperability it's not completely delivered in the sense that right now we do have a stack of standards which has made it a lot easier to interoperate, but once you start going into complex data types for example between Java and .NET or between other type of technologies you do start running into vendor specific issues. In the last 5 years I've seen a great effort from vendors, especially working for Microsoft, I've seen that they invest more in terms of providing guidance and advice and things that allow you to define the standards. The standards in a number of areas are participating in them but I think even more important having a team that works on and provides patterns and practices so we've published the patterns and practices for interoperability, we've published toolkits, we've also conducted webcast on how to interoperate with again specific technologies, with IBM WebSphere. How to interoperate with specific technologies that we do realise our customers have invested in. My suggestion would be that if you are going to implement interoperability solutions, number 1: do know that it is possible and number 2: do your research so that beyond the person that comes in and shows you double click and shows you a "Hello World" application going from Java to .NET, go to a forum, go to our MSDN forums and look at the issues that people are facing and we've solved, So that you know in advance what you are getting into. In the context of Web Services, particularly related to the WS-I basic profile which is a sub-stack of standards that a number of vendors, 170+ have agreed to test their products with each other. It's not a guaranteed interop solution but if you you're using a sub-stack of the WS-I basic profile, then your web services are more likely to interoperate than not.
7. What are some of the things you can do to address security in your development process?
That's a great question and something that I am personally and Microsoft as a company is very passionate about. As you're aware Microsoft has invested a huge amount of time, resources and efforts in the last few years, to radically improve the security in our products. There are a number of data points that we can share with your readers about what we have done. In particular a couple of things: first of all, once you start talking about services you're really talking about security in a number of different contexts. As you said securing your own application was hard enough, but now you're talking about services which means that even within the organisations they will be multiple groups using it, you're possibly talking about opening services up to your customers, possibly using internet as a communication mechanism etc. So you really need to take another look at security and there are a couple of things that you can do in this regard. First of all make sure you have a security expert in your organisation. If you don't have one then think about hiring one or getting in touch with somebody that really knows security because one of the things that I've seen when working with customers, is that no matter how many code reviews you go through in terms of peers, no matter how much testing you're gone through from a quality assurance perspective, unless you have somebody who knows what you're looking for; so you have to be a security expert in order to identify security vulnerabilities, otherwise you're basically checking the code from a quality perspective and that does not really mean there's also good quality from a security perspective. That would be my first advice: either develop expertise within your organisation or hire expertise that allows you to do things like threat modelling, identifying possible areas of attack and then reviewing code that shows how you could do better coding and identifies it. Slowly you'll see that people are also starting to learn but initially it's very critical to have people who know what they are looking for. Microsoft has actually issued something called a "security development lifecycle" which is a process that integrated with our software development lifecycle resulted in an absolutely awesome improvement in terms of the security issues that we were facing. That document is available as well as we work with our customers to actually help them incorporate security within their particular software development lifecycle.
8. So that is part of the whole "Secure by Default" Initiative.
That is correct. So you want to be secure by default or by design. The idea is that security is as everybody is finding, it is not a cliché that you're only as strong as your weakest link, so you may have all the firewalls in the world but that is not going to prevent your website from getting attacked if you're doing something in the development core that actually allows the hacker to import something that they could actually go all the way in. We do things like "hack and defend" workshops, it's really interesting to see the looks on their faces when we conduct the "hack and defend" workshops and also this is technology agnostic so it really doesn't matter if they are using Oracle, Sequel server, Microsoft technologies, Sun technologies etc. A lot of the attacks that occur can be done on any technology that you're using and you really need to have good development practices and you need to have your developers understand how hacking occurs. Of course you have to make them swear they've never used that knowledge, but once the oath has been taken then you really need to show them how hacking occurs and what are the kinds of coding issues that won't by caught by compiler or even be caught by a tool that they have to change in order to defend against the security issues.
It is very frightening and also very amazing that we see that. We go to customers that really have very mature organisations, in the financial institutions for example. In other areas they have a group of people, maybe 300 really good developers. We go to them and we often realise we need to know more about the coding and programming in .NET technologies because I don't write as much code as I used to. I had to work hard to add value to them. On the other hand it is surprising to me that a lot of those competent developers have never gone through any security training, have never seen how a hacking attack looks like, have no clue about how something that may be excellent programming practice can really become a liability if you are going to get attached. I think it's imperative; it's everybody's problem, whether you're an executive or an architect. It is extremely important to have security testing done and have security part of the process throughout rather than having it as an afterthought and doing some king of server hardening towards end, which is the maximum extent of security review that many organisations go through.
That's where the Security Development Lifecycle can play a good role and again you can actually take the security development lifecycle document and process and customise it to the needs of your organisation. Security development lifecycle defines a number of steps and in each phase of the security development lifecycle you'll have specific security steps built into your architecture, into your project plan and unless those steps are done you're not finished. You can not get through that phase unless you have completed those security tasks. It also adds specific areas where you not doing anything but security stuff. The cost of adding that one or two weeks, is smaller than the cost you need to pay in terms of your image, of terms of financial loss, of just customers getting scared of your website once they realise that it's not secure. So investing that 2-3 weeks period depending on the project that you have is a really valuable investment that you should make and it should be part of the architecture and also of the software development lifecycle for you.
Absolutely. Those quality checks are done by people that are either doing it for a living or know exactly what to look for. So it's not being done by peers who might be really good programmers but do not know a cross-site scripting attack might occur, how SQL injection attack is implemented or what is a buffer overflow. It's sort of a separate knowledge that you should have in there in the security and that's something we want to emphasise here.
Absolutely. So just from a Microsoft standpoint. This is not a marketing plug for Microsoft because we are not really a consulting company; we work with a lot of partners. For example within Microsoft we have something called the ACE security team that works with our customers, that has the expertise in Java and .NET and as I mentioned a large number of these attacks are technology agnostic in nature. They are occurring whether you're using any database, any web server, any middle tier application server or operating system, so they are technology agnostic in nature and what we have done because we realise our customers have different IT environments, is to work with customers and we do have expertise that basically shows you how to go out against these and get this technology agnostic attack. Then of course large network of partners, partner companies that have expertise in both J2EE side and the .NET side, they work with our customers to insure that their IT environments are secure its in everyone's favour whether you're IBM or Microsoft. It's in everybody's favour to make sure that the IT products that are coming in are secure. I think as an industry that's a challenge that we face industry wide and transcends any particular IT vendor.
13. I'd like to thank you for showing your time with us today. Do you have any final words?
Thank you very much. I appreciate the opportunity and I'm looking forward to this awesome new tool that's going to become available to our audiences. I'm looking forward to reading it myself as well. In terms of final words just a couple of quick notes I guess. The first one, just recopying the things that we talked about; around SOA make sure that you do your research and I'd also say "Don't be on", there are always those that take an opposing view . I would also say "Take an objective decision, look at the data that's available, look at the case studies, see if it makes sense for your organisation but do it with the object of research. What we are seeing in industry is more and more people adopting it and are finding it as something that's useful for them. In terms of security, again security is not an afterthought, it is everybody's problem. Make sure that you include it in all your designs and processes. In terms of interoperability, it is a reality. It can happen, it will have to happen, and again there are viable alternatives, although there are issues, depending on what particular version, on what particular product you use, but again there are glitchtes, but it is extremely possible to implement systems that have diverse technology; .NET front-ends with J2EE servers interacting with .NET servers; .NET servers interacting with Oracle; J2EE with SQL 2005, etc. You really do have choices and the "best of breed" concept is becoming more possible now. Finally something about my blog: I do write quite frequently about these topics at http://blogs.msdn.com/mohammadakif. I encourage you to visit my blog.